What is CIM ?

“CIM - Computer-Integrated Manufacturing. The integration of computer control and monitoring into a manufacturing process”

The Classic Model for Computer Integrated Manufacturing typically splits the Control and Monitoring functions of an Automation System into 4 discrete levels:

Level 1

The plant transducer level was traditionally connected to the control system by input and output cabling for each point of digital or logic signals and by analogue cabling for continuously variable controls.

Today plants are increasingly making use of intelligent transmitters and I/O systems with serial data cabling, or field buses. These field buses provide significantly more information such as fault and calibration type data as well as the measured signal itself.  This data is extremely useful and can save significant man hours in fault finding and tuning, however it also adds something like an order of magnitude in terms of the number of signals that the control system must deal with.

The resulting complexity has in many cases also increased by an order of magnitude and requires enormous quantities of design man hours to gain the promised benefit.

OAenterprise’s object based approach can significantly assist the design and implementation of complex processes because a class or template can be written and tested for each type of transducer and this class can generate as many objects as the plant has physical transducers. What’s more the objects do not need to be tested as far as their internal functionality is concerned because this has been done at the class level.

The benefit obtained from this approach increases the higher the number of identical or similar equipment. This makes it possible to make use of all the information generated by sophisticated plant transducers.

Level 2

This traditionally consists of either a PLC or DCS in order to directly control plant I/O and process loops. As stated above the plant physical I/O can come in as hardwired input and output cabling or increasingly as field bus type interfaces with large quantities of information on each physical field bus.

Plants with a requirement for large quantities of digital type I/O and fast execution times have traditionally chosen PLC architecture and those with a requirement for analogue type continuous I/O and slower control loops DCS architecture.

Since the trend is to use I/O with its own field bus then the picture of a PLC or DCS system as a large I/O scanning machine is changing to being a processor for the execution of control programs.  The only difference between such a PLC and a standard PC is that the PLC has an operating system designed by the hardware vendor and is memory based ie does not have discs. There is no reason why such a processor could not be a VME type processor architecture running say Windows Embedded XP or even a standard PC running a control engine over the top of the standard operating system.  This is likely to be the trend in the future.

OAenterprise is designed to handle both the PLC and DCS functions in a single software and hardware environment. The speed of modern computers and operating systems and the availability of Embedded Windows XP hardware has made it possible to achieve all but the most demanding of applications in this environment.  This common architecture means reduced support and training costs as well as significantly simpler expansion options. In addition the ability of OAenterprise to run redundant objects on other physical machines means that high reliability systems can be implemented.

As far as PLCs are concerned third party operator interface systems are commonly attached. Whilst very workable it nevertheless nearly always requires a different system at additional cost with entirely new programming methods and interfaces.  They are generally not complicated for today’s Engineer, however have their own support, expansion and hardware requirements that are completely different to the underlying control system.

OAenterprise on the other hand has an inbuilt graphics generator and display system that is completely integrated into the control system.  The OAenterprise display system (OA2view) can seamlessly be used for display of any of the levels of control.

Level 3

Level 3 is the supervisory or complex control system.  It is typically (but not always) the layer that must interface to the business systems.  This is also the software layer where the environment changes from being based upon physical I/O and direct control of machinery and equipment to being based upon abstract data that is required to be manipulated in order to ensure that the equipment knows how and in what order it should produce saleable product. This can for example be the sequencing of batches through a plant or ensuring that customer orders are produced to plan.  In manufacturing environments these are frequently called manufacturing execution systems or MES where as wide area networks more commonly use a SCADA system.

These systems are nearly always executed on a computer environment.  They are generally the link between the pure business system such as an ERP and the control systems that run the plant. In this case the Level 3 controller must convert from the transaction based ERP system that uses abstract data such as orders, stock and delivery schedules into the physical setup and control instructions for the plant.  Generally buffering in the level 3 system is required to ensure that transaction based ERP data is ready in plenty of time to generate level 2 data which is time critical.

This link has, until very recent years largely been done by pen and paper.

This level also quite often involves historisation and sophisticated alarming. Level 2 systems are generally poor at historisation because they use memory resident code on specialised hardware for executing real time control. They do not have long term storage devices such as discs because that was seen to decrease reliability.  The inclusion of disc drives require continual maintenance and this is at odds with aim of Level 2 systems which is to keep running no matter what.

Historisation is becoming more important both because:

• large and sophisticated plant is often difficult to fault find at the time of the fault
• there is much more need for generating evidence of statutory compliance in many areas of business
• there is often a requirement to be able to perform a full trace of the history of product batches in the event of a customer complaint or injury to the public.

A historian system must, by its nature, be disc based in order to provide long term storage of data. This is the area where the control system must by necessity change from being a pure memory resident architecture to one that requires physical disk drives.  Care must be taken to ensure that the data storage rate does not exceed disc access times or that so much data is logged that it fills discs very quickly.

This requirement usually means that the control system can not be totally maintenance free as data must be periodically archived to off line storage if it is to be kept for long periods. A conscious decision must also be made as to whether the control system will allow the plant to continue to run in the event that the disc drives run out of space. In the case of strict compliance requirements this may not be desirable.

SCADA systems have long required historisation or logging functions as well as reasonably sophisticated alarming.  This has been necessary because they are used for wide area systems and thus the operator can physically see very little if any of the plant he is controlling.  As far as industrial control is concerned these functions are a comparatively recent requirement and as a result they are more often than not, an add on third party product.

OAenterprise also has a historian built into the standard system.

Alarming has become a big issue because the systems that a single operator is expected to manage is becoming significantly larger and more complex. It is very easy for the operator to be completely confused and virtually rendered useless because floods of alarms keep appearing on the screen. The OAenterprise alarm system recognises this problem and provides facilities for the designer to divide alarms into plant areas, to determine in which operational states the alarm should be active and to determine the severity level of each alarm.  The aim of this sophistication is to allow operators to deal with the very important issues and then come back later to alarms of lesser importance.

Level 4

This comprises the business system such as an Enterprise Resource Planning system or ERP.  These systems are all based upon standard relational databases and hence are transaction based machines rather than the event driven memory resident systems used for real time control.  This architecture is sufficiently different to remain separate systems and hence our view is that the customer should purchase best of breed for this level and have expert people organise an interface between the two systems. We believe that this will remain the case for the foreseeable future.