The Steel Wire Rod Mill Level 2 is running under Microsoft
Windows. It was firstly customized from the Level 2
supervisory system for EAF, LMF and Caster, all developed by a
Metal Pass employee. It then was added with the Level 2 models
for rolling process and product development. The general functions of data collection,
data communication and process tracking, etc. are sufficient for the
steel wire rod mill operation. The model prediction, in which
Metal Pass is a worldwide expert, provides top quality results
for guideline of the mill operation.
Level 2 collects PLC data (with PLCSrv), testing properties
testing lab) and operation data (such as delay, event,
parts life, personnel, etc., from HMI with
Data Server), etc. All the data are saved in the MMFs
Data Server reads data from MMFs and sends them to HMIs,
while DBLog gets data from the MMFs and stores them in the
Database server (like Oracle database).
Scheduling, Predicted properties, chemical analysis, roll
information, as well as energy and material consumptions, etc. are
also the key functions and are implemented in various
sub-systems, such as the Data Server, Piece Tracking and
testing lab (Chem
testing lab application collects laboratory testing
Figure 1: Level 2
As one of the key sub-systems, the Data Server application
manages all the communication to and from the HMIs, the
communication from Lab, and the communication to and from other
level 2 servers, including mirroring in database, user actions, etc.
It is a network communication program that implements a server
socket using a connection-oriented service over TCP/IP.
There are some model screens for the application. The models predict
rolling/cooling process parameters such as force, torque,
temperature, roll gap, water box status, etc., for each pass, based on existing input
data of the current piece and the learning from the past
pieces. It also
predicts rolled steel properties.
Here the DBLog is taken as example to demonstrate the
high-performance of the Level 2 system. Current networking
technology in the industry still cannot guarantee that the
Level 2 server and database server are connected all the time.
This is due to the limitation of both hardware and software of
the networking. In this situation, in order to avoid the data
loss, lots of efforts were made in the Level 2 implementation.
The DBLog application is used to implement one-way
communication from Level2 to database, like inserting, updating or even
deleting records. The purpose of this application is to keep
the logical separation of the
Level2 system from the database, so that
the Level 2 can run smoothly without data loss even when the database is
down or the connection between Level 2 and database is broken.
As illustrated in Figure 2, DBLog performs all the inserts,
updates and deletes made from the
Level 2. Each Level 2 application
that may need to perform any of these operations builds a
request object and inserts it in a shared queue object, and
then sends a message to DBLog, which takes this request and
tries to perform it. In case the database is down, or the network
connection to the database server is broken or any error in the
request at SQL level, DBLog inserts a line in each related log
files. Then removes the request from the queue and continues
with the next requests, until all of them are performed.
Figure 2: Functionality of Level 2 DBLog, with
relationship with others
In the Figure 2, the Msg1 is a message used to communicate
with L2Monitor (a program to manage and monitor all Level 2
sub-systems) and other Level 2 applications, while Msg2
handles database related requests. Two shared memory areas are
assigned to store requests from other applications (queue1)
and database related requests (queue2). Two Dynamically Linked
Libraries, DLL1 and DLL2, are used to communicate with MMFs
and Database, respectively.
With the development of the .Net technology, new ways of
the memory management are implemented instead of the earlier
ones (shared memory).
DBLog represents the link between Level 2 and database, so all
the tables that may be affected by the Level 2 are really
accessed with DBLog. DBLog does not directly affect any of the HMI screens.
HMI Screens in the Level 2
The Human-Machine-Interface (HMI) screens and related
client-side applications were developed with Visual Basic.Net.
Several dozens of screens exist for the Level 2 package. All
screens are well developed, with a data summary screen, as in Figure
below as example.
Figure 3: An
example of HMI Screens
in the Level 2
Besides the HMI
applications, there is a
separate program that is
also written in VB.Net. It's
a parameter editor used
by a Level 2
administrator to edit
Level 2 database
parameters. For example,
the names of
operators and shift
supervisor, the chemical
analysis of each grade,
and roll types,
etc, can be pre-entered
into the Level 2 flat
file database. So for example, as long
as a grade name is
assigned in the
schedule, the technical specification
of the grade, as showed
in the above screen, is
in the Level 2.
company and personnel profiles. Please contact
us via email
firstname.lastname@example.org or by phone (001)
503 516 9625 for top quality