The MES Software Model

I have talked earlier about the importance of data in MES software.If I separate the software into "Data Consumer" or ERP,"Data Processor" or MES and the "Data Producer" which includes both the plant processor generated SCADA as well as the manually generated production reports, this allows us to move further towards data integration.

ERP providers typically build an enterprise model and constrain all other data inputs to fit( allowing for customisation).The SCADA providers typically cocentrate, as they should on running the production machinery in the first place, and offering use of historical data stored.No solution provider has as yet concentrated on the production report end.

It is in the interest of the users to come up with a specification or "contract" that will allow any ERP to combine with any SCADA and any provider of Production Report solutions.As a preliminary step I suggest the following:

For all Production Report functions:

1.The Data Consumer should accept data from only the Data Processor.

2.The Data Producer should provide data only to the Data Processor.

3.The Data Processor should obtain data only from Production Reports and SCADA(i.e. the Data Producer).

4.The MES data will be a superset of the ERP production data.

This will ensure that while MES reports will focus on an area totally different from the ERP, the reports will be consistent with each other because the underlying data are consiastent with one another.

MES for Hot Dip Galvanizing Lines-V

A SAMPLE STOCK REPORT(SCREENSHOT)

Manufacturing Execution Software(MES) for Hot Dip Galvanizing Lines: an update.

The setup I described in my earlier blogs soldiers on. Here are some new developments:

1. The configuration has been revised from an assembly of Local Server Units to one Central Server Unit surrounded by client computers forData Entry, Report Generation and admin.The revised setup is shown at Fig 1 at the start of this article.


2. The Finishing section has been added incorporating finishing, packing, loading, shipping, warehousing, contractor payments , updated stock figures.


3. Jasper Reports have been used for reports involving a lot of sub-groups and sub-totals.The output is slick and impressive.A sample is shown at the start of this blog.

MES for Hot Dip Galvanizing Lines-IV

Manufacturing Execution Software(MES) for Hot Dip Galvanizing Lines)- Frequently Asked Questions.

Q.What hardware resources did you use to build the demo MES?

A.The Local Server Unit(LSU) is running on a Pentium P4 desktop machine with a 2.6 GHz Processor and 256 MB RAM.The client machines are similar( three have been linked).The operating system in use is Windows XP.An optical fibre intra-plant network is used for the inter-connection.

Q.What software was used?

A.Java JDK 1.5.0_06 was downloaded and used on development platforms.A Java JRE of the same version was downloaded and installed on computers not used for development.The Apache Derby 10.1.1.0 database was downloaded and installed in all computers using this software.
I wrote ,compiled and installed the software programs as Java applications.

Q.What licensing costs are to be paid for these?

A.Nothing for Java and Derby.For terms of use, refer relevant documentation.

Q.How stable is the set-up?

A.Amazingly stable.In the last nine months of operation I have not backed up the database even once.(I do not recommend this practice in production set -ups,however).The server has never crashed.

QHow frequently is the set-up used?

A>It is in use 24 hours a day, 7 days a week.Roughly 100 or so entries are made daily.About a dozen connections are made daily from clients to generate multiple reports.

Q.What is the size of the records stored in the database?

A.Pretty small.Nine months records for two Galvanizing Lines occupy only around 9 MB of storage.Considering that the standard size of a new Hard Disc is 80 GB, storage space is never going to be a constraint for the use of this software.

Q.Why don't you use professional reporting environments such as Jasper Reports for reporting?

A.I have not tried to do so.I may be wrong, but it is my understanding that a reporting software "pretties up" reports- something essential for corporate presentation - at the expense of flexibility.

I conceive of the MES as the ultimate flexible tool for data mining, generating reports on the fly, may be totally new ones, depending on the Plant Managers' current needs- not as a Corporate Presentation tool.

I agree, how ever,that this is a direction that future development may take.

Q.You have only mentioned the benefits of using this software.What is the down-side?

A.The down-side is: this is not packaged, configurable software.

Many important helper classes have been written as beans, which can be reused.Many methods have been written so that they can be "copied and pasted" into new code. The pattern of any new GUI will be the same.

However, there is no escaping the fact that each separate new application will have to be rewritten.

This might sound like a lot of work but believe me, the amount of grief, time and trouble it will eliminate during ERP implementation is so much that the work is well worth it.

The sequence for developing this software is as follows:

1. Study of production process flow.
   
2. Study of production reports.
   
3. Receipt and study of written clarifications from user.
   
4. Receipt of report requirements from user.
   
5. Development of database structure, and its acceptance by user.
   
6. Off-site programming.
   
7. Off-site testing.
   
8. On site installation, data entry and testing.
   

QDo you recommend installation of this software before, or after the ERP is installed?

A.Before, without a doubt. It will provide a very good platform for trouble-shooting the Production Module for the Steel Plant ERP, immeasurably increasing user satisfaction and reducing implementation problems in the most flaky part of the Steel Plant ERP's.The same database structure for the production module can be used while designing the ERP, leading to a seamless integration of the two layers.

Q.What is your approach to security?

A.The principal element of security is in the configuration itself.

Each LSU has only the aggregate production reports for a production unit group, not high- security material itself.The computer is kept with production workers or supervisors, under the responsibility of the Plant Manager.Outside access is always very restricted in these conditions.Client connections are given selectively.On the other hand, operators should not lock themselves out of database access at two in the morning.

Under these conditions, a comparatively low security model has been installed in the demo .It can be increased as per the user's requirement,with a trade-off of reduced convenience.

Q.Is it possible to access the LSU from a browser through the Internet?

A.Yes.The Derby database supports access through the internet.Additional classes and methods can be written to provide Internet access.However, you will have to set up a separate web server for each LSU, and this is the biggest task.

Q.Can I contact you for further information?

AYes. E-Mail me at gautam.ganguli@gmail.com.

MES for a Hot Dip Galvanizing Line- III

The Relationship Between ERP and Manufacturing Execution Software(MES)

Introduction
In my previous article I had described the set-up of Manufacturing Execution Software, or MES as a number of Local Server Units, or LSU's acting alone, each networked to its own clients.Based on observations over the last few months,I had concluded that such software yielded powerful analytical results on their own.

I now turn to what further needs to be done and tested.

One of the main objectives of the MES software was, that it should submit production data, or a subset of this data to the ERP Server so that :

• The complete factory production data can be interlinked.
  
• The complete factory production function can be interlinked with all the other enterprise functions.
  
• The submission should be automated as far as possible to reduce input time, errors and cost.
  

A suggested configuration is shown in Figure 1 below:

Figure 1

Only 3 LSU's are shown linked to the ERP in the figure: in actual fact there could be a dozen or more.

The work of the Java application below the ERP is the following:

• Connect, in turn, to each LSU.
  
• Extract the data, or the required subset of the data from each relevant table in each
  database attached to each LSU, convert into a text-file of the type understood by the ERP database and submit it to the ERP database.
  
• Some additional tables may exist in the ERP: eg. the inventory between production units.These tables are also to be updated.
  
• The updation of the data will typically be done once a day.
  
• The entire process will be automated.
  

Validation of inputs.

I have already mentioned that identification of input batch, or coil numbers is a major problem. A coil may have wrong, or no labels.Of 90 billets making up a batch number, only 87 may be found.The list of problems is endless.

The nature and extent of the problem varies across organizations( reflecting managerial competence) and within shops in an organization( there are genuine difficulties in crowd wed and ill laid-out shops).Nobody has ever estimated the percentage of correct labeling within a steel plant.I have been in plants operating at 100% correctness, and in plants where achieving 95% accuracy would be considered an accomplishment.

To circumvent this issue, the best way is to design a "loosely coupled" ERP database, that uses the batch id number for its records, but does not break when the inserted id is blank, or invalid. When this happens, certain specific queries will return "no information available", but major reports to management will remain unaffected.The blank or invalid numbers can be put in a separate table, to be mapped against the correct id at some future date, if it can be found.The number of invalid ids generated by a department can be reported to management as an indicator of departmental efficiency.

In myconcluding article I will answer some questions relating to the demo set-up of the MES software that is currently in operation.

MES for a Hot Dip Galvanizing Line: Part II

The Client -Server Architecture of the MES

What we have seen so far are fairly simple data entry forms to be used by production operators to fill up a database.What is interesting is how others can mine and use the data.

The databases are local; one attached to each producing unit.A single Java application embeds the database and the server.Call this a Local Server Unit, or LSU:

Fig.1

THE LSU resides and operates in one computer. The Plant Manager queries this database and generates a variety of reports using a different networked client computer, which hosts and runs his client program.More than one manager may be interested: they can all link to the LSU (simultaneously, if need be) with their own client computer and program.A high degree of concurrency will not be supported, and is not required.Occasional access by several people around the clock is necessary, and is possible.

The user interface of the Client Program is simple:

Fig.2

A large number of sophisticated dynamic queries are stored in the program, to generate reports on the fly at the click of a button after entering the input parameters.The input parameters are the start date and the end date.It is thus possible to generate, on the fly, reports pertaining to yesterday, the last week, the previous month or a given quarter: according to your choice.Most reports are generated as printable tables.Here is an example:

Fig.3

In addition to the stored dynamic queries, the GUI accepts the user's own SQL query, if he is inclined to write one.A correctly written query will generate a printable table for viewing and/or printing.

Other reports are more complex, and are generated to an output file for printing.Here is an example:

  XYZ CO. LTD
  PRODUCTION REPORT
Galvanizing Line #2
From: 13/10/06          To: 13/10/06
AMMONIA_SPF,KG/T          3.628
AMMONIA_TOT,TONS          0.600
ANTIMONY__,TONS           0.020
AVERAGE_CRTH,MM           0.443
CHEMIDITE_SPF,LTR/T       0.121
CHEMIDITE_TOT,LTR         20.000
COATING_AVG,GSM           122.779
DROSS_PERCENT,%           8.267
DROSS__BOT,TONS           0.000
DROSS__TOP,TONS           0.530
LEAD_TOTAL,TONS           0.000
LENGTH_TOTAL,MTR          53806.000
POWER_SPF,KWH/T           175.333
POWER__TOTAL,KWH          29000.000
TIN__TOTAL,TONS           0.030
UNIKLEEN_SPF,KG/T         2.418
UNIKLEEN_TOT,TONS         0.400
WEIGHT__EXPORT,TONS       0.000
WEIGHT__FX,TONS           0.000
WEIGHT__NFX,TONS          0.000
WEIGHT__PRIME,TONS        139.926
WEIGHT__S1,TONS           21.580
WEIGHT__S2,TONS           1.544
WEIGHT__S3,TONS           2.350
WEIGHT__S4,TONS           0.000
WT_FULLHARD,TONS          145.534
WT_MIXEDHARD,TONS         19.866
WT_SOFT_TL,TONS           0.000
WT____SOFT,TONS           0.000
WT____TOTAL,TONS          165.400
ZICN_HIGH_G,TONS          5.901
ZINC_ALLOY,TONS           0.460
ZINC_PRWEST,TONS          0.000
ZINC_SPECIFIC,KG/T        35.556
  XYZ CO.LTD
  GAUGEWISE REPORT
Galvanizing Line #2
From: 13/10/06    To: 13/10/06
CRTH       GPWT
0.220       2.350
0.314       12.418
0.315       21.020
0.366       19.028
0.450       39.178
0.490       12.280
0.536       59.126

Fig.4

The 34 rows in the first part of the report is, in fact, a Union of 34 separate dynamic SQL queries designed to cover all the parameters that a Plant Manager monitors to assess the operating health of his Galvanizing Line.As before, this report can cover any arbitrary period in the Line's operating history stored in its database.The second part of the report is the result from a single dynamic query.As before, the entire page is generated within 1 or 2 seconds at the click of a button.

Some reports have too many fields to be conveniently displayed on the GUI.They are output to a text file, for conversion to an Excel file before printing.Here is an example:

Fig.5

The relationship between the LSU and the ERP will be covered in my next article.

MES for a Hot Dip Galvanizing Line

Manufacturing Execution Software(MES) for a Hot Dip Galvanizing Line

The Hot Dip Galvanizing Line is a plant used for coating steel strip with zinc to increase its resistance to corrosion.It is an economically important product.

These plants are manufactured to various levels of sophistication and complexity, depending on strip thickness range, strip width and line speed. For a typical plant layout, visit this link.
Conceptually, a Line comprises the following sections:

A pre-cleaning section.
A cleaning section.
The galvanizing pot, with an air-knife to control the zinc thickness on the strip.
A post-galvanizing surface treatment to "passivate" the galvanized strip- i.e. enhance its corrosion resistance under certain conditions.
Other processes may be optionally installed.
The rest of the equipment is to manage the strip as it moves through the line.

Galvanizing Line Management
Operating parameters, more than a dozen in number, must be continuously monitored to ensure:

The maintenance of quality.
Cost reduction.
Enhanced zinc pot life.
All the operating parameters can drift, pointing to a lack of control in a specific area. Monitoring of parameters, and acting as per the report are extremely important operational considerations.

The software
I developed a Java application using an embedded Derby relational database (freely downloadable) to warehouse the production reports from our Galvanizing Lines #1 and #2.

On double-clicking the application icon the user screen opens, with all buttons except the "LogIn" button disabled.The screen announces that the database is closed: one has to log in to open.

Figure 1.

The next image is that of a typical production report filled up for one coil, ready to be clicked into the embedded database.

Figure 2.

The consumption report, which is filled out once a shift, or once a day( depending on management practice) is shown as the next screen:

Figure 3.

TheNature of Data in an Enterprise

The Nature of Data in Enterprise Software.

In my first article of this series, I had talked about the reasons that interested me in this topic .

If I am going to design an enterprise-wide package for a steel producing company, I must understand and consider the nature of data: where it is generated, by whom it is entered, by whom it is used and for what purpose.

Accountants and production engineers in a Steel Plant typically look at data in different ways.An accountant needs consistent and verifiable data, either authenticated by the generating department, or generated by the Accounts department itself.The data is posted :either into Ledgers and Journals, or into a Computer Program by office staff trained and held accountable for accurate clerical work.Books of Account, and Management Information Reports for presentation to the Corporate Office or Statutory Authorities are prepared using this data.

Production shops, on the other hand, represent important "generating departments" in Steel Plants.The generating method is the time-honored production report.In a typical production shop (assuming that there is anything typical in a collection of production shops using such a wide variety of inputs and producing an equally wide variety of outputs) the report generation stage proceeds something like this:

Coal or iron ore stored in silos, a ladle of molten steel, an ingot, a bundle of rods bearing a specific batch number, a coil, a packet of sheets- all these can be inputs, and most of them can be outputs.It depends on the particular shop we are considering.
The input details are entered in the production report form.The unique identification no. has to be verified by the production department( for solid steel this number is usually written on the steel surface, else embossed in steel tags attached to the packet bundling wire, else pasted as paper labels on the top of the coil).Production practice may or may not call for weighing of the batch before taking it into production: in case the batch is not weighed, the output weight is taken from the production record of its previous process.
Output is usually weighed at the end of the process.On occasion weigh scales are not conveniently located, or may be under breakdown. In that case, typically "calculated" weights are used, with verification of output weights being (or not being) done at a different time and location.Sometimes the verification takes place weeks or months after production at the start of the next process.The delay is sometimes the result of a decision by Production Planning Department; sometimes the constraint is a purely physical one( material lying at the bottom of a heap).The environment is typically hot and dusty; the data is entered round the clock by production workers and supervisors primarily charged with monitoring and maintaining the production process.
In this environment the generated data is bound to be imprecise.The amount of imprecision in production data would depend entirely on the management structure, and also the data field involved.
Why should any attention be paid to imprecise data? Because they are ubiquitous, wide-ranging ,unbiased , consistently produced over long periods of time and cost virtually nothing to generate.Production engineers use statistical methods to analyze these reports to get valuable information which form the basis of quality improvement and cost-reduction initiatives.This information is valuable, available nowhere el else, and should be considered to be a data warehouse to be profitably mined at a future date.

Once we acknowledge the nature of production data, we can look at using a subset of this data, properly filter it to ensure consistency, and port it directly to the ERP. The filtration process will call for manual intervention; the more precise the shop-floor data, the less the filtration effort required.The architecture for the incorporation of production data into ERP software that emerges is a Data Warehouse application layer located below the ERP , to be used for Data Entry and Verification as well as Data Mining.

The only problem that remains is the impatience of Senior Management with the non-intuitive science of Statistics.If anyone tries to micro-manage a production process using discrete bits of data rather than taking a statistical view, he could end up by over-correcting the process, creating new problems rather than solving old ones.It is better to leave production management to professionals and hold them accountable for results.

I shall discuss my experience with the demo Data Mining program I installed in my next article.

ERP software for steel plants-I

My Encounter with Enterprise Resource Planning Software for a Steel Plant.

I do not believe that ERPs are sure-shot enablers of Corporate efficiency- and I am not alone.Too many horror stories of disastrous corporate experiences with ERPs abound.For starters read Patricia Barton's article.
To be fair, Ms. Barton's article lists those companies which have reaped outstanding benefits from ERPs as well.Which leads to the issue of the corporate planning required for a successful ERP implementation, an area where Management Consultants operate. Since I am not one of this breed, I will avoid this angle altogether.
My own experience occurred some time ago, and relates to my background.I am an old school engineer, experienced in Steel Plant production and projects. Along the way I acquired an interest in Java programming and Relational Databases.
The company I work for plunged into the implementation of an ERP on the advice of its auditors. Although not part of the company's computer department, I had one interaction session with the Vendor as one of the users in the Production Department.I received a rude shock when the vendor insisted that there had to be a standard bill of material for a particular product.
Now a steel plant has a particularly nasty( from the point of view of an ERP implementation) mix of batch and process production: the bill of material is usually obtained as an output of the analysis of production data rather than an input.My attempts at explanation were disregarded, politely by my own Computer Department, and assertively by the vendor.I clammed up, waiting for the unmentionable to hit the fan- which it unerringly did, six months later.Bitter wrangling, blocked payments, a stalled program- all the typical ingredients of a botched project were the outcome.
The lack of a highly experienced project leader, or the lack of domain knowledge on the part of the vendor, or the lack of adequate Management appreciation of the hazards of ERP implementation could have been the cause of this problem.So at an ERP conference conducted by one of the World leaders in ERP implementations I broached the problem of the Production Module for Steel Plants to one of their experienced Sales Managers.
"Steel?" was the reply."That's a process industry. The production module doesn't work too well here."So I learnt nothing new. I battled on.
"Why don't you guys have user-friendly data input?" I asked."Typically, a Steel Plant generates dozens to hundreds of production reports a day. These reports constitute the Company's data warehouse.No manager would like to scrap these, they give him quite a bit of control over the production process.Much quality and cost improvement measures follow the analysis of this data.They are filled out by busy operators and supervisors as part of their job and cost nothing to generate. Why do I need to hire a team of data-entry operators to fill out a subset of this data separately on a computer, constantly impeded by a computer system that complains incessantly about invalid data input?"
"Subset, eh?" was the reply."Why don't you capture the input as it is in a separate database, to be ported directly to the ERP application on an intermittent basis?"
Now that was a thought.Fed up by the delay in ERP implementation, I had installed a network-enabled Java application with an embedded open-source database at the company's Galvanizing Lines.By almost slavishly following the existing production report format, I had managed to coax and cajole the supervisors to simultaneously enter the data in the computer and fill in the production reports.I had designed complex queries that allowed me to generate the type of answers that a Manager needs at the click of a button.It was a non-communicating island of non-communicating information, granted, but it provided valuable information in its own right.All I need to do now is to write a separate application that will upload the required subset of data from the embedded database to the one residing on the ERP server: a very doable project.
As far as the "invalid data input"is concerned, this relates almost exclusively in Steel Plants to incorrectly identified input batch numbers ,packet numbers or coil numbers.The best way to resolve this is by using barcode readers and writers.
As we do not use these items, there will have to be manual intervention at the data transport stage.Even so, it is infinitely preferable to the drudgery of having to read and retype hundreds of fields in a day, praying all the while for no human error in the process.
Above all, the emergent model is now intereting.We now have two tiers of information: one at the operational level, useful for all kinds of analysis not interesting to the Corporate Office. The other, a subset of this data, automatically generated through computer program, goes into the ERP.There is no inconsistency.
What will be the outcome? Maybe I'll have something to say once the project is done. Purists might complain, but life is a compromise.Meanwhile we may save the ERP yet.
I am going to develop this idea further. Please click on this link for the next article.