Mill Level 2 Model Improvements Project Series
Three Level 2 systems were developed for Cascade Steel Rolling Mills
LLC, a steel minimill in the West Coast of USA. They include EAF Level 2, LMF
Level 2, and Caster Level 2. The systems are Windows-based Level 2 packages,
developed with C/C++ as implementation language, Oracle as database server, and
VB for interface language. Several aspects, especially programming for the
Windows-based Level 2 systems, were extracted here for discussion, as outlined
Three Level 2
Level 2 General Functionality
Level 2 collects PLC data (with PLCSrv), Chemistry data (with Chemlab
from chemical lab) and operation data (such as delay, from MMI with
DataSrv), etc. All the data are saved in the MMFs
(Memory-Mapped-Files). The DataSrv reads data from MMFs and sends them
to MMIs, while DBLog gets data from the MMFs and stores them in the
Database server (like Oracle DB).
Scheduling, Steelmaking recipes, chemical analysis, personnel, event,
part life as well as energy and material consumptions are also the key
functions and are implemented in various sub-systems, such as the Data
Server, Heat Tracking and Chem Lab.
Level 2 General Functionality
As one of the key sub-systems, the Data
Server application manages all the communication to and from the HMIs,
the communication form Lab the communication to and from others level
2 servers, including mirroring in DB, user actions, etc. It is a
network communication program that implements a server socket using a
connection-oriented service over TCP/IP.
There is a model screen for each of the
application of EAF and LMF. The models predict parameters based on
existing input data of the current heat and the experience of the past
Here the EAF DBLog is taken as example of
the sub-systems. The DBLog application is used to implement
one-way communication from L2 to DB, like inserting, updating or even
deleting records. The purpose of this application is to keep the
logical separation of the L2 system from the DB, so that the Level 2
can still run smoothly 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 L2. 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, the network connection to the DB 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.
Functionality of Level 2 DBLog, with relationship with others
In the Figure 2, the Msg1 is a message used to communicate with
L2Monitor and other Level 2 applications, while Msg2 handles DB
related requests. Two shared memory areas are assigned to store
requests from other applications (queue1) and DB related requests
(queue2). Two Dynamically Linked Libraries, DLL1 and DLL2, are used to
communicate with MMFs and Database, respectively.
The connection to the DB is implemented using either ODBC or ADO
technology. In this writing the ODBC technology was chosen because of
the speed and reliance of its connections, plus its easy
DBLog represents the link between Level 2 and DB, 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.
Here again, the DBLog is taken as example for the system
Three classes are involved:
- L2DBLog: Initialize the MFC Windows project and call the DBLogDlg
- L2DBLogDlg: Contain most of the Level 2 specific functions, some
being used in implementation of others. It also include some necessary
Windows programming functions.
- L2DBLogCmd: DLL class used to assemble SQL commands. The key
function in this class is FormQuery(), to be called by the DBLogDlg
member functions to query the Oracle database table.
In general, functions in the three classes perform three major types
- Windows programming: VC++ project setup (e.g., InitInstance(),
OnPaint(), OnReqLive()), Version control (e.g., LoadVersion()), MFC
messaging (e.g., MngMsg(),OnInitDialog()), etc.
- Error trapping and recording:
LogMsg(), OutString(), ODBCErrorEx(), OpenConnection(), etc.
- Connection to DB, run SQL commands, and write to log: GetDescription(),
LoadConfigFile(), Execute(), ExecuteCmd(), OnDBReq(), OnDBReql(),
SendRequestToFile(), FormQuery(), etc.
Figure 3: Classes in the DBLog Module and their functionality
Details of the classes are shown in Figure 4.
Figure 4: Class L2DBLog, L2DBLogDlg
The class L2DBLog is mainly used to initialize the application. The
major functionalities are implemented in the class L2DBLogDlg.
The function FormQuery(), the major member function of the dll class
L2DBLogCmd, is called by the DBLogDlg member functions to query the
Oracle database table.
Classes and global data structures in the Caster Level 2
Here is an example on the Caster Level 2
class structure and data handling. All classes are associated with a
set of kernel classes (the included classes in the figure below),
which were implemented separately, by derivation of
composition, etc. Those kernel classes take a set of global data
structure as their properties. Each of the global data structure hold
a set of data. Some structures also hold substructures. This is a very
efficient way to manage data and classes.
Figure 5: Classes and global data structures
in the Caster Level 2
VB Screens in the Level 2
The Human-Machine-Interface (HMI) screens
and related client-side applications were developed with Visual Basic.
Over fifty screens exist for the Level 2 package. Some screens, such
as the summary screens for EAF, LMF, Caster and Meltshop overview,
are used in more than one sub-package (EAF Level 2, LMF Level 2,
Caster Level 2, etc.). Figure 6 below is the LMF Summary screen.
Figure 6: LMF Summary screen
Besides the HMI applications, there is a separate program that is
also written in VB. It's a parameter editor used by a Level 2
administrator to edit Level 2 database parameters. For example, the
name of the operators and shift leader, the chemical analysis of each
grade, and recipe definition, etc, can be pre-entered into the Level 2
flat file database for Level 2. For example, as long as a grade name
is assigned in the schedule, the chemical analysis specification (Aim,
Min, Max value for every element, as showed in the above screen) is
displayed automatically in the Level 2.
Back to the Project