This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
2.2.1. One Goal ............................................................................................................................................................................... 12 2.2.2. Three Needs .......................................................................................................................................................................... 12
2.2.2.1. Standard & References (State of the Art) ............................................................................................................................................. 12 2.2.2.2. Good Automation Practices .................................................................................................................................................................. 12 2.2.2.3. Rapid Application Development .......................................................................................................................................................... 12
2.2.3. Five E2ASY Paths ................................................................................................................................................................. 12 2.2.3.1. Emulation for early de-risking + Fail Safe for auto-recovery ............................................................................................................... 12 2.2.3.2. Effectiveness for ahead diagnostics ...................................................................................................................................................... 12 2.2.3.3. Agility for last minute changes ............................................................................................................................................................. 12 2.2.3.4. Simplicity always in mind .................................................................................................................................................................... 12 2.2.3.5. Yes we comply ..................................................................................................................................................................................... 12
2.2.4. Key points Summary ............................................................................................................................................................. 13 2.2.4.1. Three major needs ................................................................................................................................................................................ 13 2.2.4.2. 5 outstanding features........................................................................................................................................................................... 13 2.2.4.3. 4 elementary managers manage the following features ........................................................................................................................ 13 2.2.4.4. 4 elementary actuators incorporate the following features ................................................................................................................... 13 2.2.4.5. In addition ............................................................................................................................................................................................ 13
3.2.3.1. Black .................................................................................................................................................................................................... 16 3.2.3.2. White .................................................................................................................................................................................................... 16
3.2.6.1. "Out of scope" ...................................................................................................................................................................................... 17 3.2.6.2. "In the scope" ....................................................................................................................................................................................... 17 3.2.6.3. Risky Station ........................................................................................................................................................................................ 17 3.2.6.4. Black Box Scope .................................................................................................................................................................................. 17 3.2.6.5. White Box Scope.................................................................................................................................................................................. 17
3.3. Tests Procedures .................................................................................................................................................... 18 3.3.1. Black Tests ............................................................................................................................................................................ 18
3.3.1.1. "State transition" .................................................................................................................................................................................. 18 3.3.1.2. Imperative vs Sequencing Logic .......................................................................................................................................................... 18
3.3.2. White Tests ............................................................................................................................................................................ 19 3.3.2.1. "Data Flow".......................................................................................................................................................................................... 19 3.3.2.2. "Branch/Decision" ................................................................................................................................................................................ 19 3.3.2.3. Standard Model .................................................................................................................................................................................... 19
4.3. Embedded Features ............................................................................................................................................... 43 4.3.1. Real Time OEE for Ahead Diagnosis .................................................................................................................................... 43
7.3. Diagram .................................................................................................................................................................. 79 7.4. Public Data ............................................................................................................................................................. 79
7.4.1. Program Manager .................................................................................................................................................................. 79 7.4.2. Program Track ....................................................................................................................................................................... 79 7.4.3. Motions Group ...................................................................................................................................................................... 79 7.4.4. Motions Array ....................................................................................................................................................................... 79 7.4.5. Outputs Array ........................................................................................................................................................................ 79 7.4.6. Inputs Array .......................................................................................................................................................................... 79
7.5. Interfaces Configuration ....................................................................................................................................... 80 7.5.1. Motions Interfaces vs Stations ............................................................................................................................................... 80 7.5.2. Outputs- & Inputs vs Stations ................................................................................................................................................ 80
8.3. Diagram .................................................................................................................................................................. 82 8.4. Public Data ............................................................................................................................................................. 82
Preparer: Your signature indicates that you prepared this document.
Reviewer: Your signature indicates that, as a subject matter expert, you have reviewed the content of this document and agree its contents are accurate.
Approver: Your signature indicates that this document respects regulation requirements of Good Manufacturing Practices and Good Documentation Practices. You agree with its structure and its relations with others validation documents
Automated machine programming is typically done by software engineers, machine designers, and system integrators. The form and style of the machine software ranges from modular, to monolithic in nature. The objective of this project is to specify the application of a common software methodology that is consistent with the modular programming of automated machinery as described in the ISA-88 standard. This project enables a consistent method of machine interconnection and operability.
2.2. Objective
In pharmaceutical industry the most required systems are Rockwell or Siemens.
2.2.1. One Goal
The SW_Platform defines 1 design guide lines for 2 PLC so only one HMI should comply with anyone.
2.2.2. Three Needs
Beside the unique HMI goal, there are 3 targets to keep in mind:
2.2.2.1. Standard & References (State of the Art)
versus ISA-S88, ISA-TR88.02 and ISO-13849
2.2.2.2. Good Automation Practices
with specifications, tests and validation
2.2.2.3. Rapid Application Development
"Time is money", "Ready early", ...
2.2.3. Five E2ASY Paths
After few technical performance tests, activity based costing analysis and normative references studies, the 5 following matters appear to be the right paths to achieve the 3 main targets.
2.2.3.1. Emulation for early de-risking + Fail Safe for auto-recovery
To pre-test and failure-compensate process sequences
2.2.3.2. Effectiveness for ahead diagnostics
Detailed real-time OEE at every level for ahead diagnosis and to identify predictable failures
2.2.3.3. Agility for last minute changes
Through combination of specialization ability and flexible aggregation, "lego mindstorm"
2.2.3.4. Simplicity always in mind
To make programs running earlier and faster with less files, data, code, bugs, pain, money...
2.2.3.5. Yes we comply
With standards & references so we reuse supplier's codes without reinventing wheel.
This platform is ready in ladder and structured-text (two PLC prototypes are coded). It applies the rules promoted by ISA-TR88. 8 reusable routines are defined (Admin, Prog, Track, Nest, Bin, Num, Cam and Pls) and the task "Admin" contains 3 routines (logic-actuators-alarm). Compared with the 1200 instructions lines of the 60 routines of current platforms, these 11 basic routines requires around 100 lines that give technical and economical affordable "modular testing". By testing three instructions lines at a time, this platform is validated in white box after 35 hr of effort (with prior written tests).
2.2.4.1. Three major needs
• Compliance TR88, 1st model for mecatronics iAssembly and Packaging industries.
• Rapid application development software, "ARD" to reduce costs.
• Adoption of best automation practices (Gamp 5).
2.2.4.2. 5 outstanding features
• Emulation with actuators included for offline de-risking and online safe mode ability.
• Real-time OEE included in each module for self-diagnostic and preventive maintenance.
• Agility by recombination of the 4 elementary actuators already established on PDS, and EQW1 RAI01.
• Simplicity with only 3 routines per station (logic-actuators-motions) and only 1 config file per machine.
• Compatibility with TR88 and Gamp5 (modes, states, alarms, data-in, data-out, mnemonics, etc. ...)
2.2.4.3. 4 elementary managers manage the following features
• The OEE in real-time in the three managers (Admin, Track and Nest).
• Enhanced limp mode by selecting Nests and / or Tracks.
• Synchronous and asynchronous sequencer (program).
• Management of operating modes and states (Admin).
• Part-ID and Shift-Register data monitoring.
• Management of multiple recipes (Admin).
• Batch Management (Admin).
• Consecutive errors.
• etc ...
2.2.4.4. 4 elementary actuators incorporate the following features
• Single or dual acknowledgement for alarm (HMI and / or Enclosure).
• The safety and self-recovery after operator acknowledgement.
• Manual controls without any additional programming.
• The real-time OEE calculations in the 4 actuators.
• The actuators time response emulation.
• Fail Safe Mode by emulation.
• Mirroring (probe mode).
• etc ...
2.2.4.5. In addition
The automatic generation of "test cases" and modelling "control activity" (HMI, SCADA, Recipe, Batch, etc. ...) is still in progress. The configuration file defining sequencers and data of one machine with its stations have a macro that generates the symbols and instructions lines directly into a Rockwell PLC; the same configuration file also contains all the required information for a machine SDS.
To terminate and by joining the actual software platform activity based costing, Komax should be able to save between 30% and 40% of software development cost while complying to medical requirements.
The main purpose of this document is to describe how to implement the E2ASY paths to achieve the 3 main targets (State of the Art, Good Automation Practices and Rapid Application Development); to do so, the first chapter summarizes the Gamp advises while the second proposes a design process that comply with the normative references; the latest chapters give practices details for hardware interfaces, administration, machine, station and actuator software design.
2.3.1. Gamp Guide Lines
Gamp guidance aims to achieve computerized systems that fit for intended use and meet current regulatory requirements, by building upon existing industry good practice in an efficient and effective manner. It promotes the system V life cycle approach; it synthesizes the goals of tests and gives some typical procedures for modular testing. This chapter gives also the standard software project plan, it lists the software categories and our changes control practices.
2.3.2. Design Guide Lines
The design guide lines goes quickly through the ISA-S88 / IEC-61512 models that have initiated the ISA-TR88 (PackML); it shows how it could be structured in matter of physics, configurations, programs, machine modes, machine states, station states and actuator states. Then it reminds UML's analysis that confirms the ISA's arguments wisdom; the analysis feedbacks objects, states, sequential and class diagrams. It depicts the specifics features embedded into every main class such as effectiveness calculations, time response emulation, components agility and simplicity. The configuration conventions are covered by following the TR88 organization through controller administration, machine and station scopes. The last part proposes a design process for software engineer as development guide lines.
2.3.3. Hardware Interfaces
There is no automation software without hardware; this chapter gives a standard topology that complies with machine directive 2006/42/CE. It proposes a classified list of standard components that could be used with this platform and how to drive them from a software point of view. Then it gives short descriptions of operator panel uses, lights tree behaviour and HMI screens requirements.
2.3.4. Admin Details
This chapter gives to the software engineer the keys to configure admin programs; It explains how to size the machine stations, "tracks side" quantity and "nests side" quantity; It goes again through every public tags that have been considered as "Admin" components; It reminds the "Admin" components could be locally or remotely controlled; It describes the dedicated HMI screen.
2.3.5. Machine Details
This chapter gives to the software engineer the keys to configure a machine programs; it shows how to configure station tags, private and public; it describes the dedicated HMI screen.
2.3.6. Asynchronous Stations Details
This chapter gives to the software engineer the keys to configure asynchronous (or transactional) station programs; it explains how to configure actuators, its "tracks side" quantity and "nests side" quantity; It gives clues to make the sequencer that manage the chosen actuators; It shows how to configure station tags, private and public; It describes the dedicated HMI screen.
2.3.7. Synchronous Stations Details
This chapter gives to the software engineer the keys to configure camshaft synchronous station programs; most of it is the same as asynchronous station but it explains how to merge the standard sequencer to the camshaft follower.
2.3.8. Actuators Details
This chapter gives to the software engineer the keys to configure actuators instructions;
It shows some examples how to choose, instance and configure the right actuator class.
The V Life Cycle principle structures the development by coordinating the design, implementation and validation phases; successive versions of Gamp have continued to strengthen this model.
PerformanceTesting
User Requirements
Specification
ModulesSpecification
DesignSpecification
FunctionalSpecification
Integration &Modules Test
InstallationTesting
OperationalTesting
MachineMachine
ActuatorsActuators
StationStation
Black BoxBlack Box
BlackBox
BlackBox
WhiteBox
WhiteBox
Configuration _00
–
+Configuration _01
Main form _01Tags List _01
+ Sub form _01_00
Sub form _01_01
Sub form _01_02• Actuators List• Station Sequences
–
–
Project _A
Project _B
+
Sub form _01_010++
• Stations List• Mach. Sequences
The downswing starts with the customer's specifications that the supplier translates into multidisciplinary functional specifications, which means they are common to all trades that the provider must implement to achieve the final product.
These functional approaches are then taken up sector by sector (mechanical design, hardware and software) to prepare design specifications, those ones, because of their too high level of abstraction, are again taken to be detailed to establish concrete references to the implementation phase.
The design phase ends with the jobs (mechanics, hardware & software) specifications writing of the modules, these specifications are translated into mechanical drawings, electrical diagrams and software diagrams (states, objects, sequences or classes).
The upswing is completely symmetric in terms of tests, so from Gamp, a different type of test is required for each phase of implementation, so the pre-integration tests validate the modular testing achievements, the installation validate the jobs requirements, the operational tests confirm the choices and finally the functional performance tests qualify the final product relative to customer specifications.
Ensure proper operation on the specifications of a portion of the program (called "unit" or "module"):
o A test procedure for each module.
o A test module independent from the rest of the program.
o Ensure that performance correlates the specification of that module.
o All tests must be replayed after a code change to ensure the absence of instabilities.
The Extreme Programming advocates writing the test procedure at the same time that the function of the module is coded.
3.2.2. Modules
All software studio providers offers a standard way of viewing the project organization and may be called "Program Organization", "Project Explorer" or "POU", they all have the purpose to show a tree to determine the overall software modules nesting into each other or with each other ...
Therefore each of the icons listed in the Explorer is a module that can be tested with the exception of modules that contain only data ("tags") is still the case because most controllers are not yet fully object-oriented and continue to separate data programming instructions or code.
3.2.3. Box
3.2.3.1. Black
Example: the transistor
A "black box" is a module of unknown internal composition (voluntarily or not).
The black box test is used to verify that the results are the expected ones for given conditions. It is therefore appropriate as soon as the test is more important than the code behind.
3.2.3.2. White
Example: the bicycle
A "white box" is a module which can forecast every feature because all components are visible.
The white box testing is done by scanning the source code of the module during its own execution; the online stepping mode could be a mean to achieve this test.
Unit tests take place before the installation tests stage: they are part of the integration testing stage; the protocols contents of these tests are based on modules specifications.
ModulesSpecification
Integration &Modules Test
MachineMachine
ActuatorsActuators
StationsStations
Black BoxBlack Box
BlackBox
BlackBox
WhiteBox
WhiteBox
Code In Scope:-Custom Process-Parts Information-Batch Supervision
Tests applicable on functions identified as critical on the pFMEA
Tests applicable on actuators identified as high-risk class in the SRA
pFMEA
S R A
3.2.5. Software Architecture
Unit testing is necessarily dependent on the chosen software architecture, in the field of assembly or packaging automatic machines, the latest standards require the following architecture: a machine is divided into stations and each station is an aggregate of actuators.
These standards describe only how to structure portions of program support to automate processes, parts of program schedules related to "Firmware" or "Fieldbus" commonly called "Platforms" are not affected.
3.2.6. Architecture & Scope
For the validation of a machine and only in case the base system comes from a recognized provider (Siemens or Rockwell the platform testing are not required; at most, the end customer may request a certificate respect of the recommendations of use ("good practices") established by the provider after an audit of our PLC platform using Komax guide lines.
3.2.6.1. "Out of scope"
We consider "beside" codes related to the systems (Siemens or Rockwell) integration in our platform does not fall within the scope of unit testing.
3.2.6.2. "In the scope"
We consider the specifically written code to automate processes required to assemble, process or trace the product for the custom application enters in the scope of unit testing.
3.2.6.3. Risky Station
In fact, all modules are tested more or less by programmers, electricians and mechanics between the machine power-up, configuration and tune-up. Therefore some unit tests are probably not needed on the whole modules in charge of the process of a machine, a machine would not consider every station as risky for the product. For unit tests, we consider only the modules belonging to stations where a risky process is identified.
3.2.6.4. Black Box Scope
Modules and sub-modules of a "risky station" identified by the "Software Risk Analysis" black box
are tested, including the main module when its white box testing is done.
3.2.6.5. White Box Scope
Only the main module of a "risky station" is subject of a white box test.
To qualify a white box, we recommend the "Branch / Decision Testing" in cases of logical sequenced and the "Data Flow Testing" in other cases (i.e. "Part Info" or "Shift-Register").
3.3.2.1. "Data Flow"
This analysis identifies the interactions between components connected by data flow and / or flow control. The test cases are designed to perform transfers between variables or values of components and require the following information:
The input variables.
Places of definition of variables and pairs of uses.
The subsets of control flow (s) to run.
Expected results.
3.3.2.2. "Branch/Decision"
The source code analysis make possible the branches identification with their expected results. A branch is an instruction executed in a conditional expression. Test cases are designed to execute combinations of values in the branches and require the following information:
Identification and inputs of each branch.
The identification of combinations of values to run.
The expected results and / or identification of the next branch.
Under sequential logic, this technique requires a "step by step" mode of operation.
3.3.2.3. Standard Model
Here the number of programs to be tested in white boxes is the number of existing stations.
The software revision number is a part of the PLC project naming convention.
It defines the file name (with the date).
It defines the controller name (without the date).
3.6.1. Revisions Numbering
_.xx while the software project is controlled by the software engineer in charge of coding.
0.00 Right after "Inputs Check" at the beginning of "Test-Up" (see §5.1).
0.xx while "Modules Tests" without "Revisions Traceability" but with "Program header update".
1.00 right after "Integration Tests"
1.xx while "Operational and Performance Tests" with "Revisions Traceability".
2.00 right after the FAT.
2.xx after the FAT with "Revisions Traceability".
3.6.2. Revisions Traceability
A word document is attached to each revision; it describes each change with screenshots of codes changes (before and after) and with a comment of the modification; this makes the change historics, which includes "Test Reference", "Modification Title", "Why" reason, date and author.
The diagram shown here are specific in terms of the functionality they provide but can be implemented in various ways to fit most automated machinery and machine controllers; therefore the figures do not follow the standard UML guidelines for depiction of software flow.
Procedural
Model
Operation (s)
Recipe
Procedure (s)
Phases
Procedural
Model
Operation (s)
Recipe
Procedure (s)
Phases
Operation (s)
Process
Stage (s)
Actions
Process
Model
Operation (s)
Process
Stage (s)
Actions
Process
Model
Unit (s)
Area (s)
Cell (s)
Equipments
Modules
Physical
Model
Plant (s)
Enterprise
Unit (s)
Area (s)
Cell (s)
Equipments
Modules
Physical
Model
Plant (s)
Enterprise
Activity
Model
Process Management
Unit (s) Supervision
Process
ControlP
roduction,
Pla
nnin
g a
nd
Schedu
ling
Recip
es
Managem
ent
Info
rmation
Managem
ent
Activity
Model
Process Management
Unit (s) Supervision
Process
ControlP
roduction,
Pla
nnin
g a
nd
Schedu
ling
Recip
es
Managem
ent
Info
rmation
Managem
ent
4.1.2. TR88 / PackML
If automated machinery is modelled in an ISA-S88 physical hierarchy, it is possible that a machine can represent the unit level in this hierarchy; It also known as PackML standard.
A Line (Cell) contains all of the Machines (Unit), Station (equipment) and Actuator (module) required to make one or more batches.
Process control activities must respond to a combination of control requirements using a variety of methods and techniques. Requirements that cause physical control actions may include responses to process conditions or to comply with administrative requirements.
A frequently recognized subdivision of a Line (Cell) is the train. A train is composed of all Machines (Unit) and other Stations (equipment) that may be utilized by a specific batch. A batch does not always use all the Stations (equipment) in a train. Furthermore, more than one batch and more than one product may use a train simultaneously. The order of equipment actually used or expected to be used by a batch is called the path. Although a Line (Cell) may contain more than one train, no train may contain equipment outside the boundaries of the Line (Cell).
A Line is a logical grouping of equipment that includes the equipments required for production of one or more batches. It defines the span of logical control of one set of process equipments within an area. The existence of the Line allows for production scheduling on a Line basis, and also allows for Line-wide control strategies to be designed. These Line-wide control strategies might be particularly useful in emergency situations.
4.1.2.2. Machine
A Machine (unit) is made up of Stations (equipment) and Actuators (module). The Actuators (module) that make up the Machine (unit) may be configured as part of the Machine (unit) or may be acquired temporarily to carry out specific tasks.
One or more major processing activities can be conducted in a Machine (unit). It combines all necessary physical processing and control Stations (equipment) required to perform those activities as an independent Station (equipment) grouping. It is usually centred on a major piece of processing Stations (equipment). Physically, it includes or can acquire the services of all logically related Stations (equipment) necessary to complete the major processing task(s) required of it. Machines (unit) operate relatively independently of each other.
A Machine (unit) frequently contains or operates on a complete batch of material at some point in the processing sequence of that batch. However, in other circumstances it may contain or operate on only a portion of a batch. This standard presumes that the Machine (unit) does not operate on more than one batch at the same time.
4.1.2.3. Station
Physically, the Station (equipment) may be made up of Actuators (module) and subordinate Stations (equipment). A Station (equipment) may be part of a Machine (unit) or a stand-alone Stations (equipment) grouping within a line. If engineered as a stand-alone Station (equipment) grouping, it can be an exclusive-use resource or a shared-use resource.
A Station (equipment) can carry out a finite number of specific minor processing activities such as dosing and weighing. It combines all necessary physical processing and Actuators (module) required to perform those activities. Functionally, the scope of the Station (equipment) is defined by the finite tasks it is designed to carry out.
4.1.2.4. Actuator
An Actuator (module) is typically a collection of sensors, probes, valves, motors, other Actuators (module), and associated Stations (equipment) interlocks that, from the point of view of control, is operated as a single entity. An Actuator (module) can also be made up of other Actuator (module). For example, a header Actuator (module) could be defined as a combination of several on/off automatic block valve.
Some examples of Actuators (module) are
a regulating device consisting of a transmitter, a controller, and a control valve that is operated via the set point of the device;
a state-oriented device that consists of an on/off automatic block valve with position feedback switches, that is operated via the set point of the device;
A header that contains several on/off automatic block valves and that coordinates the valves to direct flow to one or several destinations based upon the set point directed to the header actuator.
Note: Actuators (module) do not perform procedural control, only imperative (ISA-S88 §5.2.2.4.2).
The hierarchy's process tree complies with the P&ID tagging:
Line, 1 project title.
Machine, _Mn, 3 digits.
Station _Mn_Ss, 6 digits.
Actuators, _Mn_Ss_Aa, 9 digits.
The result is a total discrimination on each component based on their hierarchy level. This open approach makes also possible to treat sub-machine(s) and sub-station(s).
4.1.4. Configuration
There is no difference between the physical components and the project written data:
Line, 1 directory
Machine, 1 file.
Station, 1 machine file form.
Actuator, 1 station form column.
One to one link between physical components and configured components.
4.1.5. Programs
There is no difference between the physical components, the project written data and the PLC's programs organization of use (POU's):
Line, 1 PLC.
Machine, 1 PLC's task.
Station, 1 task program.
Actuator, 1 program rung.
One to one link between physical components, written components and coded items.
...
–
+ Machine _00
Machine _01
+ Station _01_00
Station _01_01–
Station _01_02 • Program Tags• Program Logic
–Station _01_02 • Program Tags• Program Logic
–
–
Line _A
Line _B
+
Sub. _01_010+
▼ ▼ ▲embedded within stations
▲ ▼ ▼ ▲ ▲
Actuators
▼ ▼ ▲▼ ▲▼
▲ ▼ ▼ ▲ ▲▼ ▲▼ ▲▲
Stations
▼ ▲▼ ▲▼ ▲ ▼ ▲
Machine (s)
▼ ▲ ▼ ▲▼ ▲▼ ▲
Line (s)
▼ ▲▼ ▲
Configuration _00
–
+Configuration _01
Main form _01Tags List _01
+ Sub form _01_00
Sub form _01_01
Sub form _01_02• Actuators List• Station Sequences
A Unit/Machine control mode is an ordered subset of states, state commands, and state transitions that determines the strategy for carrying out a unit/machine’s process. Typical Unit control modes are Automatic, Semi-Auto, Manual, Index, Jog, Purge, Clean, Dry Cycle, etc. The distinguishing elements between these Unit control modes are the selected subset of states, state commands, and state transitions.
4.1.6.1. Producing
This represents the mode which is utilized for routine production. The machine executes relevant logic in response to commands which are either entered directly by the operator or issued by another supervisory system. The Base State model below can be used to define a Producing mode that is used in order to deliver control of routine processing and production. It is recognized that machines also require maintenance, calibration, and setting up. To address this requirement two example modes of operation are shown below: Maintenance and Manual.
4.1.6.2. Maintenance
This mode may allow suitably authorized personnel the ability to run an individual machine independent of other machines in a production line. This mode would typically be used for alarm-finding, machine trials, or testing operational improvements. This mode would also allow the speed of the machine to be adjusted (where this feature is available).
It is expected that, because the machine will generally operate in its usual manner, it will need to undergo some or all of its routine starting up procedures. Maintenance mode will follow a recognized unit state model.
4.1.6.3. Manual-Emulation
Manual mode provides suitably authorized personnel the ability to operate individual subordinate equipment controls (such as actuator) within the machine under manual pushbutton control. Such controls in this mode may be on a "hold-to-run" basis such that removal of the run signal will cause the actuator to be stopped. The ability to perform specific functions will be dependent upon mechanical constraints and interlocks. Manual mode will be of particular use for setting up the machine to work.
This provides direct control of individual machine modules. This feature is available depending upon the mechanical constraints of the mechanisms being exercised. This feature may be used for the commissioning of individual actuators, verifying the operation of synchronized actuators, testing the actuator as a result of modifying parameters, etc...
Emulation refers to the ability of a program to emulate (imitate) physical device, in this mode, the time response emulation that is embedded in every actuator could be enabled; it means some machine equipments tune-up could be done even with some missing parts.
4.1.6.4. Purge
User mode to empty the machine (i.e. for cleaning).
4.1.6.5. Dry Cycle
User mode to execute without parts entering in the machine.
4.1.6.6. Single Cycle
User mode to execute only one cycle and ask operator for next one.
4.1.6.7. Limp Track
User mode to execute only on some track(s) (i.e. disable one or more up).
4.1.6.8. Limp Nest
User mode to execute only on some nest(s) (i.e. disable one or more nest).
A Unit/Machine state completely defines the current condition of a machine. A Machine state is expressed as an ordered procedure, or programming routine, that can consist of one or more commands to other procedural elements or equipment entities, or consist of the status of a procedural element or equipment entity, or both. In performing the function specified by the state the machine state will issue a set of commands to the machine procedural elements or equipment entities which in turn can report status. The machine state will perform conditional logic which will either lead to further execution within the current machine state or cause a transition to another state. The machine state is the result of previous activities that had taken place in the machine to change the previous state.
Only one major processing activity may be active in one machine at any time. The linear sequence of major activities will drive a strictly sequentially ordered flow of control from one state to the next state – no parallel states operating on the same equipment entity are allowed to be active in one machine at the same time.
▼ ▲ ▼ ▲
Machine(s)
▼ ▲ ▼ ▲
▼ ▲▼ ▲
Line(s)
▼ ▲▼ ▲
Suspend
Stopped ExecuteStarting
Reseting Susping
Mo
des
Ch
ang
e
Held HoldingAborting
Idle
Stoping
Aborted
Suspend
Stopped ExecuteStarting
Reseting Susping
Mo
des
Ch
ang
e
Held HoldingAborting
Idle
Stoping
Aborted
Types of States, For the purposes of understanding three machine state types are defined:
o Acting State: A state which represents some processing activity. It implies the single or repeated execution of processing steps in a logical order, for a finite time or until a specific condition has been reached. In ISA-88 these are referred to transient states, those states ending in “-ing”.
o Wait State: A state used to identify that a machine has achieved a defined set of conditions. In such a state, the machine is maintaining a status until transitioning to an Acting state or the Dual state. In ISA-88 this was referred to as a Final or Quiescent state.
o Dual State: A Wait state that is causing the machine to behave as in an Acting state. The Dual state is representative of a Machine state that can be continuously transitioning between Acting and Waiting, and Looping, as defined by the logical sequence required. As noted in ISA-88, the Execute, or Running state, is a Transient state. This Machine state has been re-characterized to also include the diversity of operation found in packaging and discrete machines.
4.1.7.1. Aborting
This acting state can be entered at any time in response to E-Stops, Unsafe-Enclosures or on the occurrence of a machine alarm defined in the abort range. The aborting logic will bring the machine to a rapid safe stop. It will also provide a signal to initiate the ABORTED State.
4.1.7.2. Aborted
This wait state maintains machine to be tripped by its safety system; all high energy equipments are powered-off and the enclosures are unlocked; subsequently any manual intervention by opening enclosures to correct and reset the detected machine alarm could take place here. The machine can only exit the ABORTED state after an explicit STOP command; this is the way to lock enclosures.
4.1.7.3. Stopping-Clearing
This acting state can be entered at any time in response to Stop-Button or on the occurrence of a machine alarm defined in the stop range. This stopping state executes the logic which brings the machine to safe conditions by checking-locking enclosures and then power-on every component. When complete or after pending alarms acknowledgment (i.e. "CLEAR" command made by Start-button), it provides a signal to initiate the STOPPED State.
This wait state means machine is powered, safe and stationary after completing the STOPPING state (Enclosures locked). All communications with other systems are functioning (if applicable). A START command will cause the acknowledgement of pending alarms and an exit from STOPPED to the RESETTING state. An ABORT command will cause an exit from STOPPED to ABORTING; this is the way to unlock enclosures.
4.1.7.5. Resetting
This acting state is the result of a START command from the STOPPED state. RESETTING will typically place the machine in a kind of "HOME" state where components are ready to execute process. When complete, it provides a signal to initiate IDLE state.
4.1.7.6. Idle
This wait state indicates that RESETTING is complete ("HOMED"). This state maintains the machine conditions which were achieved during the RESETTING state, and performs operations required when the machine is in IDLE.
4.1.7.7. Starting
This acting state is the result of a maintained START command (local or remote) from the IDLE, SUSPENDED or HELD states that causes machine to sound a horn during few second before providing a signal to bring machine to EXECUTE; if the maintained START command is shortened then it will provide a signal to initiate the IDLE state instead.
4.1.7.8. Execute
This dual state means machine is processing materials it is deemed to be executing or in the EXECUTE state. Different machine modes will result in specific types of EXECUTE activities. For example, if the machine is in the Production mode, the EXECUTE will result in products being produced, while in Purge mode the EXECUTE state refers to the action of cleaning the machine.
4.1.7.9. Holding
This acting indicates machine detects an internal equipment alarm or any internal material in-feeds lack (i.e., container feed, beverage feed, crown feed, lubricant feed, etc.) or when the HOLD command is used to start HOLDING logic which brings the machine to a controlled stop or to a state which represents HELD for the particular unit control mode. The HOLD command offers the operator a safe way to intervene manually in the process (such as removing a broken bottle from the in-feed) and restarting execution when conditions are safe. To be able to restart production correctly after the HELD state, all relevant process set-points and return status of the procedures at the time of receiving the HOLD command must be saved in the machine controller when executing the HOLDING procedure.
4.1.7.10. Held
The wait HELD state holds the machine's operation while material blockages are cleared, or to stop throughput while a downstream problem is resolved, or enable the safe correction of an equipment alarm before the production may be resumed.
4.1.7.11. Suspending
This acting state is a result of a change in monitored conditions due to process conditions or factors. The trigger event will cause a temporary suspension of the EXECUTE state. SUSPENDING is typically the result of starvation of machine upstream incoming or downstream outgoing blocked that prevents the machine from EXECUTE continued steady production. During the controlled sequence of SUSPENDING the machine will transition to a SUSPENDED state. The SUSPENDING state might be forced by the operator.
4.1.7.12. Suspended
This wait state indicates machine may be running at a relevant set point speed, but there is no product being produced while the machine is waiting for external process conditions to return to normal. When the offending process conditions return to normal, the SUSPENDED state will transition to STARTING and hence continue towards the normal EXECUTE state.
This acting state can be entered at any time in response to E-Stops, Unsafe-Enclosures or on the occurrence of any alarm. The aborting logic will bring the station to a rapid safe stop. When complete it provides a signal to initiate IDLE State.
4.1.8.2. Resetting
This acting state is the result of a RESET command from the IDLE state. RESETTING will typically place the station in a kind of "HOME" state where components are ready to execute process. When complete, it provides a signal to initiate IDLE state.
4.1.8.3. Idle
This wait state maintains the stations conditions which were achieved in previous acting state, and performs operations required when the station is in IDLE.
4.1.8.4. Execute
This acting state means the station is processing one material cycle and when complete providing a signal to initiate IDLE state.
4.1.9. Actuator States
4.1.9.1. Cmd:=1
This acting state Enables the actuator output in conjunction with time-out control; if input feedback is right then it provides signal to initiate "Sts=1" state; however if time is over before actuator input feedback is right then it provides signal to initiate "Alm1=1" state.
4.1.9.2. Alm1=1
This wait state maintains actuator to be in safe position by DISABLING the actuator physical output; the only way to leave the "Alm1=1" state is the "Cmd_Ack" command to go back to "Cmd:=1" state.
4.1.9.3. Sts=1
This wait state maintains the actuator output enabled and performs operations required to check actuators input feedback PRESENCE; The "Cmd:=0" command can end "Sts=1".
4.1.9.4. Cmd:=0
This acting state Disables the actuator output in conjunction with time-out control; if input feedback is right then it provides signal to initiate "Sts=0" state; however if time is over before actuator input feedback is right then it provides signal to initiate "Alm0=1" state.
4.1.9.5. Alm0=1
This wait state maintains actuator to be in safe position by DISABLING the actuator physical output; the only way to leave the "Alm0=1" state is the "Cmd_Ack" command to go back to "Cmd:=0" state.
4.1.9.6. Sts=0
This wait state maintains the actuator output disabled and performs operations required to check actuators input feedback ABSENCE; The "Cmd:=1" command can end "Sts=0".
With this architecture most of the code instructions takes place in the so called "Platform"; most of this instructions are used in functions called by machines and stations programs; it is very difficult to delimit the data context so any test is painful; this architecture means big efforts to comply to any customer required exception with high risk in side effects; the worst constraint is the jarring to heterogeneous programs mix (multi sources providers direct integration).
Object Oriented Programming
The basic result of an object oriented software platform is the tremendous reduction of the code instructions used by the platform itself; most of the codes take place in objects directly instantiated in the machines or stations programs; it means light interdependence between programs and platform; it means easy customisation and heterogeneous programs mixing.
4.2.2. UML's Quatuor
The Komax SW_Platform complies with Object Oriented Programming principles in order to implement Gamp guide lines while ISA-S88 figures do not follow the standard UML guidelines; the following paragraphs depict SW_Platform with 4 UML perspectives:
The object diagram in UML is a diagram that shows a complete or partial view of the structure of a modelled system at a specific time.
The state diagram describes the behaviour of a programmed device or other process works such that an entity or each of its sub-entities are always in exactly one of a number of possible states and where there are well-defined conditional transitions between these states.
The sequence diagram is a kind of interaction diagram that shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart. A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and class involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario. Sequence diagrams typically are associated with use case realizations in the Logical View of the system under development.
The class diagram is the main building block in object oriented modelling. It is used both for general conceptual modelling of the systematic of the application and for detailed modelling translating the models into programming code. The classes in a class diagram represent both the main objects and/or interactions in the application and the objects to be programmed.
There are others UML's diagrams that could be used to depict software, but those four could make it.
A machine is an aggregation of stations; and the stations are also aggregation of actuators.
Machine and stations contain the "Administration" data, while actuators do not.
Those "Administration" data are the machine "Public" commands, parameters, status, reports, statistics, accumulators, etc...
Those can be attached to tracks (machine side) and/or nests (on fixture side or conveyed pucks or pallets)
4.2.4. States Diagram
The m achine specific program only contains instructions to drive connected stations; so it only needs the same states as any stations programs.
The "Administration" program for a machine is driven by the machine states diagram that interacts with the "rest of the world" including the operator, see "Machine States" §5.1.7.
The stations programs could do their job with 3 acting states and 1 wait state; see "Station States" §5.1.8.
The actuators could do their job with 2 acting states and 4 wait states: see §5.1.9.
4.2.5. Sequential Diagram
Depending on the command "Exec" sent by the upper machine program, the station program initiates sequences that would send commands to relevant actuators, then switches to next sequence regarding actuators status, and so on to go through every defined sequence up to the completion of the current cycle that initiates the status "Idle".
Manager for Tracks (Machine or Station); it includes logic to calculate real time OEE and consecutive errors test. The tag naming conventions took place in §5.4.1.
Mgr_Prog, as reference to program manager.
Par_MaxCons, parameter to define consecutive maximum.
Cfg_OEEOff, config. to disable or reset rtOEE calculation.
Cfg_ConsOff, ccnfig. to disable or reset consecutive test.
Rep_TmrAbort, report to view aborting time accumulation.
Rep_TmrExec, report to view executing time accumulation.
Rep_CtrBad, report to view aborting sequence quantity.
Rep_CtrGood, report to view good sequence quantity.
Rep_CtrExec, report to view executing sequence quantity.
Rep_Consec, report to view current consecutive value.
Rep_OEE, report to view current real time OEE value.
Sts_Enable, status to indicate current track is enable.
Sts_AlmCons, status to indicate consecutive alarm.
Sts_Good, status to indicate last execution was good.
Sts_Bad, status to indicate last execution was aborted.
...
Sample of a station with Track0 on Side0 and Track1 on Side1 defined.
The object oriented programming incites to integrate or to embed most often required features:
Efficiencies calculation.
Software emulation.
Fail safe feature.
Some other could be added in the future...
4.3.1. Real Time OEE for Ahead Diagnosis
Every SW_Platform components embed their own real time Overall Equipment Effectiveness calculation based on real time TR88 OEE normative reference. This feature lets user find out when the machine is low in efficiency, which station is involved and finally which actuator is making trouble; it helps more than making diagnosis from alarms messages waterfalls.
4.3.1.1. TR88 Theory
From ISA-TR88, Overall Equipment Effectiveness (OEE) is a measure comparing how well manufacturing equipment is running compared to the ideal plant. The resulting measurement is expressed as the ratio of the actual output of the equipment divided by the maximum possible output of the equipment under ideal conditions. OEE is calculated by multiplying three independently measured values: Availability, Performance Rate, and Quality Rate. The fundamental OEE definition is defined as an availability ratio multiplied by a performance ratio multiplied by a quality ratio.
OEE is often displayed as a waterfall object in which the major components of Availability, Performance, and Quality are displayed graphically. Losses are further subdivided into categories within the OEE sections.
Total Time
Scheduled Stops
Planed Production Time
Fault Stops
Operating Time
Suspending
Reduced Speed
Unscheduled Stops
Total Pieces Time Credit
Startup Rejects
Good Pieces Time Credit
Processed Rejects
Curtailment
Performance = Total Pieces / (Operating Time x Rate)
Availability = Operating Time / Planned Production Time
Quality = Good Pieces / Total Pieces
O E E = (Good_Pieces x 60) / (Planed_Production_Time x Machine_Rate_per_Min)
Calculating a Real-Time OEE in a Machine Controller or HMI
This example is a simple real-time calculation based upon Pack Tags with data originating from the machine controller. This example will not require historical tracking of information and will show a calculation of OEE since the last time the machine counts and timers were reset in the machine controller. This example is recommended for machine builders and control vendors that want to show a basic OEE on their HMI systems.
The limitation of this calculation will be that it will only be valid for the time period since the last time the counts and times were reset in the machine controller. It will also be invalid if the setup or product of the machine causes the design speed of the machine to change.
o Planned Production Time is defined as the amount of time that the machine is scheduled to run production. This includes time such as changeover time, unplanned maintenance time, and major breakdowns. For this implementation, it will be assumed that the machine is always scheduled to run. The number of total seconds since the last reset occurred can be obtained using the following tag: UnitName.Admin.AccTimeSinceReset
o Operating Time is defined as the time the machine has been attempting to run production. This should be linked to the time that the machine has been in production mode. The number of seconds in production mode since the last reset occurred can be typically obtained using the following tag:
Performance = Total_Pieces / (Operating_Time x Ideal_Run_Rate / 60)
o Total Pieces is defined as the total pieces that have been brought into the machine from the primary production path. The number of units that have been brought into the machine since the last reset can typically be obtained through the following tag:
o Ideal Run Rate is defined as the maximum rate the machine can run given the current product and setup of the machine. This number may change based upon a product being run on the machine. Should this number change, then the OEE calculation will become invalid. It is suggested that if this number ever change, that a reset on the count and timers should occur. The number of units per minute for the ideal run rate can be obtained using the following tag:
NOTE: Because the unit of time for MachDesignSpeed is in minutes and the operating time is in seconds, there needs to be a unit correction factor in the above equation. We have chosen to divide the MachDesignSpeed by 60 to convert it into units per second. This will keep units consistent in the above equation.
Quality = Good_Pieces / Total_Pieces
o Good Pieces includes only good pieces during the production run. This is the main production processed count of the machine. If a filler, this should be bottles out of the filler. The number of good pieces of production that have been run since the last count reset can be obtained by subtracting the total products processed minus the products that were defective: UnitName.Admin.ProdProcessedCount[#].Count - UnitName.Admin.ProdDefectiveCount[#].Count where the # is typically 0 for both counters as a default. If multiple products are being tracked the index may change.
o Total Pieces is defined as the total pieces that have been brought into the machine from the primary production path. The number of units that have been brought by the following UnitName.Admin.ProdProcessedCount[#].Count tag that could give the last reset time: where the # is typically 0 as a default. If multiple products are being tracked the index may change.
Overall Real-Time OEE Calculation When multiplying Availability, Performance, and Quality the following equation for OEE is produced:
O.E.E. = (Good_Pieces x 60) / (Planned_Production_Time x Ideal_Run_Rate)
or
O.E.E. = Good_Pieces x Ideal_Cycle_Time.01sec / Planned_Production_Time.sec
Limitations of Real-Time OEE Equation
o The above real-time OEE equation is only valid for the time period since the times and counts were last reset in the machine controller. It also becomes invalid if the MachDesignSpeed is ever changed.
With SW_Platform, the Mgr_Adm instances located in Admin program is in charge of machine OEE report. The following waterfall diagram shows where state elapsed times are putting in account.
Elapsed time since last clear
Operating Time
Aborting
Total Parts Time Credit
Good Parts Time Credit
Performance = Total Parts Time Credit / Op. Time
Availability = Operating Time / Accumulated Time since last reset
Quality = Good Parts / Total Parts
O E E = Good_Parts x Cycle_Time_Ideal_msec / Time_Since_Last_Clear_dsec
Aborted
Stopping
Stopped
Resetting
Idle
Suspending
Suspended
Starting
Bad Parts
Holding
Held
The upper formula only covers the machine effectiveness and is coded in Mgr_Adm class; this means by default, the effectiveness could be spread in "Oper", "Shift" or "Batch" or more instances. The Cycle_Time_Ideal is in msec and the Time_Since_Last_Clear is in dsec for result in %.
4.3.1.3. Mgr_Track
With SW_Platform, the Mgr_Track instances in station program are in charge of OEE report for one of the station track side. This formula covers station effectiveness and is embedded in Mgr_Track class.
O E E = (Ctr_Good x Cycle_Time_Ideal) / Tmr_Exec
4.3.1.4. Mgr_Nest
With SW_Platform, the Mgr_Nest instances in station program are in charge of OEE report for one of the fixture side. This formula covers nest effectiveness and is embedded in Mgr_Nest class.
O E E = (Ctr_Good / Ctr_Exec) x (1 - (Tmr_Abort / Tmr_Exec) )
4.3.1.5. Act_???
With SW_Platform, every Act_??? instance in actuators sub-programs are in charge of OEE report for each elementary module. This formula is embedded in Act_Bin, Act_Cam, Act_Num and Act_Pls class.
O E E = Time_Out x (Ctr_Exec - Ctr_Alarm) / Tmr_Exec
4.3.1.6. OEEs Supervision
The detailed real-time OEE at every level gives useful information to identify predictable failures. RSLinx Topic Name
SW_Platform
Tag Name Get Value Tag Name Get Value Tag Name Get Value Tag Name Get Value
Diagnostics Station 00 Effectivenenss Operator (User) Effectivenenss Shift Effectivenenss Batch
4.3.2. Emulation for Early De-risking + Fail-Safe for Auto-recovery
Also use as "Fail Safe" feature due to its automatic and safe ability to compensate a failure.
4.3.2.1. Response Time
In signal processing, the impulse response of a dynamic system is its output when presented with an input command signal. More generally, an impulse response refers to the reaction of any dynamic system in response to some external change. In both cases, the impulse response describes the reaction of the system as a function of time (or possibly as a function of some other independent variable that parameterizes the dynamic behaviour of the system).
4.3.2.2. Principle
The SW_Platform integrates the emulation ability directly in the actuator functions; the concept is based on the "embedded time response" where the embedded timer is used to manage the movement time out while not being in emulation mode, or it is used to simulate the input feedback while being in emulation mode.
Additional benefits:
Automatic and safe ability to compensate a failure.
Simulate a part presence for "dry-cycle" purpose for instance.
4.3.2.3. Binary
See the top right sketch that applies to binary components such as cylinder, gate, conveyor, etc...
4.3.2.4. Came
Same as Numeric that applies to camshaft components such as angular axis came follower, etc...
4.3.2.5. Numeric
See the bottom right sketch that applies to numeric components such as linear axis, heater, flow-meter, etc...
4.3.2.6. Pulse
Same As Binary that applies to hysteretic components such as feeder level, flip-flop, tick control, etc...
Public definition (Controller tags declaration) _Mn_Sn_Aa_PrivateDefinition (a public tag is a private tag + _Machine_Station_Actuator_ heading) Ex: "_11_26_01_Vision1_Cmd_Abort"
4.4.1. Keys Codes Meanings
Key Code Meaning Description Type(s)
4.4.1.1. Ack Acknowledge Used to send acknowledgement to instruction / function, typically used alarms acknowledgments.
DINT, BOOL
4.4.1.2. Act_ Actuator Used to specify an actuator instruction/function. Act_...
4.4.1.3. Adm, Admin
Administration Used at the machine level beside Cmd and Sts.
"Adm" is the short form of "Admin" that is the short form of "Administration.
Any
4.4.1.4. Alm Alarm Which alarm is occurring within process. This can be either a bit-level or value-level indication. Value-based alarm annunciation allows for a large quantity of alarms to be supported within a single indicator. Bit-level alarming can support multiple alarms simultaneously, but can require a large number of indicators to support all alarm states.
DINT, BOOL
4.4.1.5. Bin Binary Used to specify a binary actuator instruction/function
Act_Bin
4.4.1.6. Cam Camshaft Used to specify a camshaft actuator instruction / function
Act_Cam
4.4.1.7. Cfg Configuration Generally used to designate a value used in configuring how the process within the instruction / functions. This is only occasionally changed. It can be entered from the HMI or as part of a recipe or batch.
DINT, BOOL
4.4.1.8. Clr Clear Generally used to designate a command used to clear accumulators, report or parameters of the process within the instruction/functions.
DINT, BOOL
4.4.1.9. Cmd Command Generally used to as a command input of the instruction/function, either from the operator via the HMI or from the program.
DINT, BOOL
4.4.1.10. Ctl Control Complex PLC 's data structures used to control PLC's specific instruction/function.
CONTROL
4.4.1.11. Ctr Counter Used to accumulate or increment any value. DINT
4.4.1.12. ...ID Identifier Used to merge some Boolean status within an integer.
DINT
4.4.1.13. Inp Input Real-time data used to drive the process within an instruction / function. Generally used to designate a connection to a real input point or a control device (local or external).
DINT, BOOL
4.4.1.14. Log Login "User" User Login status of machine. DINT, BOOL
4.4.1.15. Mgr Manager Used to specify a manager instruction/function Mgr_...
4.4.1.16. Mode Mode Mode of the process within the machine DINT
4.4.1.17. Nak None Acknowledge
Used to send none acknowledgement to instruction / function, typically used alarms double acknowledgments (none single).
Act_...
4.4.1.18. Nest Fixture Side Used to specify nest statistics manager instruction / function
Mgr_Nest
4.4.1.19. Num Numeric Used to specify a numeric actuator instruction / function
Act_Num
4.4.1.20. Out Output Real-time data driven from the process within an instruction/function. Generally used to designate a connection to a real output point, a control device, or to data sent to other process.
DINT, BOOL
4.4.1.21. Par Parameter Parameters are variables that are received from an external source, such as a batch or a recipe management system that can be internal or external to the program
REAL, DINT
4.4.1.22. Pls Pulse Used to specify a pulse (flip-flop) actuator instruction / function
Act_Pls
4.4.1.23. Prog Program Used to specify a machine/station manager instruction / function
Mgr_Prog
4.4.1.24. Rep Report Reported value designates a value (calculated inside the instruction) that is typically used for batch reporting.
REAL, DINT
4.4.1.25. ...s Array of ... Used to specify an array of data (one or more dimensions).
REAL[ ], DINT[ ]
4.4.1.26. Safe Safety Safety status of machine/station DINT, BOOL
4.4.1.27. State State State of the process within the machine/station DINT
4.4.1.28. Sts Status Status of the process within the instruction / function
DINT, BOOL
4.4.1.29. Tmr Timer Timer driven by system clock or by custom ticks DINT, TIMER
4.4.1.30. Track Station Side Used to specify machine/station tracks statistics manager instruction/function
Mgr_Track
4.4.1.31. Typ Type definition
Complex data structures made up of a combina-tion of input and output data. These structures are used to pass data in an instruction/function.
UDT
4.4.2. Tags Configuration
4.4.2.1. Description
The description is equivalent to the tag comment.
4.4.2.2. Name
The name defines the tag name.
4.4.2.3. Domain
This field could be filled with "Public" for controller tags (global) or "Private" for program tag (local).
4.4.2.4. DataType
This field defines the PLC data type related to the tag under configuration.
4.4.2.5. TagType
This field could be filled with "Alias" for referenced tags or "Tag" for unreferenced tag.
4.4.2.6. TagReference
In case of "Alias" tag type and if reference has to be defined manually, this is the right field.
In the controller main task, the programs names are related to their TR88 types.
4.4.3.1. Machine
_<Machine-ID>_<Machine-Name> (should be placed at the beginning of the task).
_<Machine-ID>_<Admin> (should be at the end of the task).
4.4.3.2. Station
_<Machine-ID>_<Station-ID>_<Station-Name>
4.4.3.3. Actuator
The Admin actuators are embedded in "Actuators_Sub" routine under "_Mn_Adm" programs.
4.4.4. Controller Tags
4.4.4.1. Admin
At the controller level, there are tags related to the TR88 Admin features; all off them belong to the machine and can be internally or remotely controlled.
Abort every process station Sts_Seq=01 Cmd_Seq:=02
Abort BaseFibro Sts_Seq=02
Config Tracks vs Mode
Manage Track Statistics
Description TagReference
Manage Prog Logic
The first form in the machine document is dedicated to the machine as the main.
MainType, could be Machine or Sub_Machine.
Main_ID, should be between _00 to _99.
MainName, the convenient machine name description.
MaindT####, Ideal expected time response.
4.5.1.3. Machine Data
The "Machine" program merges every machine private data. Description Name Domain DataType TagType TagReference
Manage Prog Logic Prog Public Mgr_Prog Alias
Manage Track Statistics Track Public Mgr_Track Alias
Motions Array Mots Public REAL[5,2] Tag _01_Mots
Outputs Array Outs Public DINT[5] Tag _01_Outs
Inputs Array Inps Public DINT[5] Tag _01_Inps
Sized for 5 x Stations with 2 x Tracks.
4.5.1.4. Stations Configuration
The stations are declared in the machine form; one station is equivalent to one column.
SubType, could be Station or Sub-Station.
Sub_ID, should be after _Mn (_<MachineID>) identifier from _00 to _99.
SubName, the convenient station name description.
SubdT####, Ideal expected time response
The latest "station" is dedicated for the "_Adm" program declaration that is always attached to any machines; for this one, no "_ID" number, just "_Adm" statement.
The "_Adm" program is always attached to a machine and "Administrate" as defined in TR88; the sequencer takes care of the machine state model, the operator panel buttons and the lights tree.
Flashing Steady Cmd_Out:=0 Cmd_Out:=0 Flashing Flash if Alm State:=10
Mach_Idle=1
Steady Flashing Cmd_Out:=0 Cmd_Out:=0 Flashing Flash if Alm State:=07
AlmHold=0
Flashing Cmd_Out:=0 Steady Cmd_Out:=0 Flashing Flash if Alm State:=12
Mach_Idle=1
Staedy Cmd_Out:=0 Flashing Cmd_Out:=0 Flashing Flash if Alm State:=07
AlmSusp=0Suspended, 12 State=12
Suspending, 11
State=09
State=11
State=07
Held, 10
State=08
Holding, 09
State=10
Aborting, 01State
Any
Stopping, 03
Execute, 08
Starting, 07
State=06
Aborted, 02
Stopped, 04
State=05
State
Any
Resetting, 05
Idle, 06
State
Any
State
Any
4.5.1.6. Admin Data
The "_Adm" program merges every machine public data
Description Name Domain DataType TagType TagReference Current State Sts_State Public DINT Tag _01_Adm_Sts_State
Command State Cmd_State Public DINT Tag _01_Adm_Cmd_State
Current Mode Sts_Mode Public DINT Tag _01_Adm_Sts_Mode
Command Mode Cmd_Mode Public DINT Tag _01_Adm_Cmd_Mode
Login Identifier LogID Public DINT Tag _01_Adm_LogID Safety Identifier SafeID Public DINT Tag _01_Adm_SafeID
Acknow. Identifier AckID Public DINT Tag _01_Adm_AckID
Alarms Identifier AlmID Public DINT Tag _01_Adm_AlmID
Alarm to Abort Alm_Abort Public BOOL Alias _01_Adm_AlmID.1
Alarm to Stop Alm_Stop Public BOOL Alias _01_Adm_AlmID.2
Alarm to Idle Alm_Idle Public BOOL Alias _01_Adm_AlmID.3
Alarm to Hold Alm_Hold Public BOOL Alias _01_Adm_AlmID.4
Alarm to Suspend Alm_Susp Public BOOL Alias _01_Adm_AlmID.5
Alarm to Warn Alm_Warn Public BOOL Alias _01_Adm_AlmID.6
Alarm to Help Alm_Help Public BOOL Alias _01_Adm_AlmID.7
Stats Clear Identifier ClrID Public DINT Tag _01_Adm_ClrID
Oper's Stats Clear Clr_Oper Public BOOL Alias _01_Adm_ClrID.0
Shift's Stats Clear Clr_Shift Public BOOL Alias _01_Adm_ClrID.1
Batch's Stats Clear Clr_Batch Public BOOL Alias _01_Adm_ClrID.2
Admin Array Adms Public Mgr_Adm[3] Tag _01_Adm_Adms
Admin Oper Adm_Oper Public Mgr_Adm Alias _01_Adm_Adms[0] Admin Shift Adm_Shift Public Mgr_Adm Alias _01_Adm_Adms[1] Admin Batch Adm_Batch Public Mgr_Adm Alias _01_Adm_Adms[2] Alarms Array Alms Public DINT[5,10] Tag _01_Adm_Alms
Camshafts Array Cams Public DINT[5,10] Tag _01_Adm_Cams
Parameters Array Pars Public DINT[5,10] Tag _01_Adm_Pars
Reports Array Reps Public DINT[5,10] Tag _01_Adm_Reps
Tracks Manager Tracks Public Mgr_Track[5,2] Tag _01_Adm_Tracks
Nests Manager Nests Public Mgr_Nest[5,2] Tag _01_Adm_Nests
Nests Empty NestEmpty Public DINT Tag _01_Adm_NestEmpty
Nest Identifier NestID Public DINT Tag _01_Adm_NestID
Part Identifier PartID Public DINT Tag _01_Adm_PartID
Pulse per Second PlsSec Public Act_Pls Tag _01_Adm_PlsSec
Motions Group Motions Public MOTION_GROUP Tag _01_Motions
Header = Manager of Program LogicHeader = Manager of Program Logic
4.5.2.7. Sequences Details
The sequence branch start with the test on the current sequence value.
Then it is splitted in two branches:
o The first one is conditioned by "Prog.Sts_SeqOns" that gives the up threshold and where the commands to the actuators take place.
o The second one is conditioned by "Prog.Sts_SeqExe" that enable the sequence to be executed and where the status from the actuators are tested.
At the right, if the second half branch conditions are all good, then the command to next sequence is written with some other station instructions such as "Prog.Sts_Safe" for instance.
4.5.2.8. Tags List
With the spreadsheet embedded macro, every station tag is merged in the tags list form.
MainType Machine Revision V001_110810
Main_ID _01 Made Komax
MainName Machine by SW
Scope _ID Name Domain DataType TagType TagReference Description
T a g s L i s t
_01_01_LoadBody _01_01_ArmAxis ArmAxis Public AXIS_GENERIC Tag _01_01_03_ArmAxis _01_01, Arm Axis
_01_01_LoadBody _01_01_ArmAxisCtl ArmAxisCtl Private MOTION_INSTRUCTION[10] Tag _01_01, Arm Axis Control
_01_01_LoadBody _01_01_ArmAxisSts ArmAxisSts Private DINT Tag _01_01, Arm Axis Status
_01_01_LoadBody _01_01_Nest0 Nest0 Public Man_Nest Alias _01_Admin_Nests[1,0] _01_01, Statistics
_01_01_LoadBody _01_01_Nest1 Nest1 Public Man_Nest Alias _01_Admin_Nests[1,1] _01_01, Statistics
_01_01_LoadBody _01_01_Prog Prog Public Man_Prog Alias _01_01, Program
_01_01_LoadBody _01_01_Track0 Track0 Public Man_Track Alias _01_Admin_Tracks[1,0] _01_01, Statistics
_01_01_LoadBody _01_01_Track1 Track1 Public Man_Track Alias _01_Admin_Tracks[1,1] _01_01, Statistics
_01_02_LoadScrew _01_02_ArmAxis ArmAxis Public AXIS_GENERIC Tag _01_02_03_ArmAxis _01_02, Arm Axis
Header rungs exactly the same codes between synchronous and asynchronous.
The synchronous sequence (#2 for instance) starts by defining the came setpoint (330° for instance). Then each rung uses a "LIM" instruction that checks if predefined angle is between "_CamAnte" and "_CamPost". The last "camshafted" rung checks reached last angle to request the next sequence #3.
The actuators are declared in the station form; one actuator is equivalent to one column.
SubType, could be Act_Bin, Act_Cam, Act_Num or Act_Pls.
Sub_ID, should be after _Mn_Ss (_<MachineID>_<StationID>) identifier from _00 to _99.
SubName, the convenient function name description.
SubdT####, Ideal expected time response
4.5.4.2. Actuators List
With the spreadsheet embedded macro, every station actuator are merged in the actuators list form where definitions extensions could added such as physical output / inputs, parameters or reports.
Scope, should be the name of the program where the actuator take place.
_ID, should be the actuator ID seen from the controller point of view (_Mn_Ss_Aa means _<MachineID>_<StationID>_<ActuatorID>).
Name, the convenient function name description.
DataType, could be Act_Bin, Act_Cam, Act_Num, Act_Pls or Alias
DataValue, expected time response or any additional parameter value.
Parameter Definition, Admin reference that gives ID number in parameters array.
Parameter Description, the text to add after _Mn_Ss_Aa_Name...
Report Definition, Admin reference that gives ID number in repoerts array.
Report Description, the text to add after _Mn_Ss_Aa_Name...
Alarm OFF Definition, Admin reference that gives ID number in alarms array.
Alarm OFF Description, the text to add after _Mn_Ss_Aa_Name...
Alarm ON Definition, Admin reference that gives ID number in alarms array.
Alarm ON Description, the text to add after _Mn_Ss_Aa_Name...
Output Definition, Physical reference that gives ID number in outputs array.
Input Definition, Physical reference that gives ID number in inputs array.
There is no automation software without hardware; this document gives a typical topology that complies with machine directive 2006/42/CE (ISO 13849-1).
The date and time to the PLCs is given by the HMI Data-Server with "Clock Update Tools". For the HMI PC clients, the date time is synchronized with Windows W32 time service.
"_Mnn_Adm" if sub-machine, should be from _000 to _999.
6.1.3. SubType
All actuators required for machines or sub-machines administration are controlled in "Actuators_Sub".
EStopsOFF checks emergency stops.
DoorsClosed checks the enclosures safety feedbacks.
DoorsLock controls the enclosures interlocks.
Alm_Buzz manages the alarms and 2sec buzzer while starting.
Alm_White manages the white lamp in lights tree.
Alm_Green manages the green lamp in lights tree.
Alm_Amber manages the amber lamp in lights tree.
Alm_Red manages the red lamp in lights tree.
But_Stop manages the stop button with its lamp.
But_Start manages the start button with its lamp.
6.2. States & Modes
The normal access goes through reactions to operator panel (E-Stop, Stop and Start buttons); however, a remote access is available through Cmd_State. Another feature manages by admin logic is Sts_Mode versus Cmd_Mode only when Sts_State=Stopped; keep in mind that a mode change make state switch to Sts_State=Aborting.
6.2.1. E-Stop
"E-Stop" button or alarms initiate the "Aborting" acting state from any current state.
6.2.2. Stop
"Stop" button or alarms initiate the "Stopping" acting state from any current state if no abort pending.
"Stop" button initiates the "Aborting" acting state from "Stopped" state to unlock the doors.
6.2.3. Start
"Start" button initiates the "Resetting" acting state from "Stopped" state.
"Start" button initiates the "Starting" acting state from "Idle" state.
"Start" button acknowledges pending alarm versus current user login.
6.3.5. Login Identifier LogID Up to 32 user access groups.
6.3.6. Safety Identifier SafeID Up to 32 enclosures to discriminate.
6.3.7. Acknowledge Identifier AckID Update from LogID if Start button pressed and pending alarm.
6.3.8. Alarms Identifier AlmID Up to 7 different types of alarms.
6.3.8.1. Alarm to Abort Alm_Abort To request Aborting
6.3.8.2. Alarm to Stop Alm_Stop To request Stopping
6.3.8.3. Alarm to Idle Alm_Idle To request Resetting
6.3.8.4. Alarm to Suspend Alm_Susp To request Suspending
6.3.8.5. Alarm to Hold Alm_Hold To request Holding
6.3.8.6. Alarm to Warn Alm_Warn To warn operator
6.3.8.7. Alarm to Help Alm_Help To help operator
6.3.9. Clear Identifier ClrID To discriminate which statistics counters needs to be cleared.
6.3.9.1. Oper's Stats Clear Clr_Oper To clear Oper's statistics
6.3.9.2. Shift's Stats Clear Clr_Shift To clear Shift's statistics
6.3.9.3. Batch's Stats Clear Clr_Batch To clear Batch's statistics
6.3.10. Admin Array Adms To manage any statistics for real time OEE
6.3.10.1. Admin Operator Adm_Oper To manage Oper's statistics (real time OEE)
6.3.10.2. Admin Shift Adm_Shift To manage Shift's statistics (real time OEE)
6.3.10.3. Admin Batch Adm_Batch To manage Batch's statistics (real time OEE)
6.3.11. Alarms Array Alms Alarms array is in 2D, one for stations and the second for severities; so a 4 stations machine would be [05,10].
6.3.12. Camshafts Array Cams Camshafts array is in 2D, one for stations and the second for camshafts; so a 4 stations machine would be [05,10]
6.3.13. Parameters Array Pars Parameters array is in 2D, one for stations and the second for parameters; so a 4 stations machine would be [05,10]
6.3.14. Parameters Length ParsLen Parameters and Camshafts Length use by "Recipe Confirm"
6.3.15. Reports Array Reps Reports array is in 2D, one for stations and the second for reports; so a 4 stations machine would be [05,02]
6.3.16. Tracks Manager Tracks Tracks managers array is in 2D, one for stations and the second for sides; so a 4 stations with 2 tracks would be [05,02]
6.3.17. Nests Manager Nests Nests managers array is in 2D, one for stations and the second for sides; so a 4 stations with 2 tracks would be [05,02]
6.3.18. Nests Empty NestEmpty Indicates when every nest are empty
6.3.19. Nest Identifier NestID 1= Nest#1 in front of station #01, 2= Nest#2 in front of station #01
etc...
6.3.20. Part Identifier PartID 1= Part ID #00001, 2= Part ID #00002,
etc...
6.3.21. Pulse per Second PlsSec Second heart beat...
6.3.22. Batch Interface Batch MES to control multiple machines vs batch
6.3.23. Recipes Array Recips Storable and restorable parameters and camshafts collections
6.3.24. Recipe Name Recipe Name of active parameters and camshafts collection
6.3.25. Recipe ID RecipeID ID of active parameters and camshafts collection
...
6.4. Diagram
All sequences defined in the configuration admin form are coded in the "Program_Logic". MainType Station SubType Act_Bin Act_Bin Act_Bin Act_Bin Act_Bin Act_Bin Act_Bin Act_Bin Revision V001_110810
The configuration of the data seen in "Admin" are based on a matrix approach where rows could be related to stations and columns to station's components.
6.5.1. Admin Statistics
Admin Statistics Operator Shift Batch . . .
Machine #01 Adms[0] Adms[1] Adms[2] . . .
. . .
6.5.2. Alarms vs Stations & Severities
Level 1 2 3 4 5 6 7
Meaning Abort Stop Idle Held Suspend Warn Help
Station #00 _Alms[0,1].n _Alms[0,2].n _Alms[0,3].n _Alms[0,4].n _Alms[0,5].n _Alms[0,6].n _Alms[0,7].n
Station #01 _Alms[1,1].n _Alms[1,2].n _Alms[1,3].n _Alms[1,4].n _Alms[1,5].n _Alms[1,6].n _Alms[1,7].n
"_Mnn" if sub-machine, should be from _000 to _999.
7.1.3. MainName
The convenient machine or sub-machine name description.
7.1.4. MaindT
The ideal expected time response in msec.
7.1.5. SubType
Could be sub_machine or station; the stations are declared in the machine form; one station is equivalent to one column. Usually machine or sub-machine do not need actuator; if not, the routine "Actuators_Sub" would be added.
7.1.6. Sub_ID
If station, should be "M" (_<Sub_MachID>) identifier from 0 to 9.
If station, should be "_Ss" (_<StationID>) identifier from _00 to _99.
7.1.7. SubName
The convenient sub-machine or station name description.
7.1.8. SubdT####
The ideal expected time response in msec.
7.1.9. _Adm
If it's not a sub-machine, the latest "station" is dedicated for the "_Adm" program declaration that is always attached to any machines; for this one, no "_ID" number, just "_Adm" statement.
7.2. States
▼ ▲▼ ▲▼ ▲▼ ▲
Stations
▼ ▲▼ ▲ Reseting
Exec.
Aborting Idle
Reseting
Exec.
Aborting Idle
7.2.1. Abort
When Prog.Cmd_State = 1 and Admin_State = 1 (Aborting) then set sequence #01.
7.2.2. Reset
When Prog.Cmd_State = 2 and Admin_State = 5 (Resetting) then set sequence #11.
7.2.3. Exec
When Prog.Cmd_State = 4 send And Admin_State = 8 (Execute) then set sequence #21.
8. Asynchronous Stations Details An asynchronous process or transactional process individuates each of its activities so that each one commits its operation before execution continues.
8.1. Header
8.1.1. MainType
Could be "Station" or "Sub-station".
8.1.2. Main_ID
"_Mn_Ss" if machine's station, should be from _00_00 to _99_99.
"_Mnn_Ss" if sub-machine's station, should be from _000_00 to _999_99.
"_Mn_Sss" if machine's sub-station, should be from _00_000 to _99_999.
"_Mnn_Sss" if sub-machine's sub-station, should be from _000_000 to _999_999.
8.1.3. MainName
The convenient station or sub-station name description.
8.1.4. MaindT
The ideal expected time response in msec.
8.1.5. SubType
Could be station or sub-station; the actuators are declared in the machine form; one actuator is equivalent to one column. All actuators required for stations or sub-stations are controlled in "Actuators_Sub".
8.1.6. Sub_ID
If station, should be "S" (_<Sub_StationID>) identifier from 0 to 9.
If station, should be "_Aa" (_<ActuatorID>) identifier from _00 to _99.
8.1.7. SubName
The convenient sub-station or actuator name description
8.1.8. SubdT####
The ideal expected time response in msec.
8.1.9. Sub Details
The actuator #00 is an "Act_Bin" named "ArmGrip" with a 500 msec timeout.
The actuator #01 is an "Act_Bin" named "ArmDown" with a 1000 msec timeout.
The actuator #02 is an "Act_Num" named "ArmMotion" with a 2000 msec timeout.
The actuator #03 is reserved...
The actuator #04 is an "Act_Bin" named "BodyGate" with a 1000 msec timeout.
The actuator #05 is an "Act_Bin" named "BodyFeed" with a 1000 msec timeout.
...
8.2. States
8.2.1. Abort
When Prog.Cmd_State = 1 and Prog.Sts_State = 1 (Aborting) then set sequence #01.
8.2.2. Reset
When Prog.Cmd_State = 2 and Prog.Sts_State = 2 (Resetting) then set sequence #01.
8.2.3. Exec
When Prog.Cmd_State = 4 send And Prog.Sts_State = 4 (Execute) then set sequence #2.
9. Synchronous Stations Details A synchronous process is invoked by a request based on camshaft angle.
9.1. Header
As §9.1.
9.2. States
As §9.2.
9.3. Diagram
All sequences defined in the configuration station form are coded in the "Program_Logic", and the first actuator has to be an "Act_Cam" that would be in charge of checking the right angles at the right time.
The sequence #01 resets every actuators and command sequence #03.
The sequence #02 executes camshaft:
o Request camshaft rotation up to angle 330°.
o Check Sts_Cam to set or reset the related actuators versus camshaft angle.
o When camshaft rotation reaches 330° angle, check actuators and commands sequence #03.
The sequence #03 ends camshaft and set "Sts_Idle" to complete sequencer.
MainType Station SubType Act_Cam Act_Bin Act_Bin Act_Bin Act_Bin Revision V001_110810
This program contains the logic to manage actuators in SYNCHRONOUS manner.
Header rungs exactly the same codes between synchronous and asynchronous.
The synchronised sequences starts by defining the came setpoint (330° for instance).
Then each rung starts with a test on sequence followed with by "GEQ" instructions that check if
predefined angle is greater than or equal to "_CamAnte". The last rung of this sequence checks if camshaft reaches the setpoint with every actuators in idle state to request the next sequence #3.
La programmation d'une machine automatique est réalisée par des programmeurs, des concepteurs et des intégrateurs. Les formes et les styles de cette programmation peuvent être à la fois monolithique et modulaire. L'objet de ce projet est de spécifier une méthode de programmation compatible avec l'approche modulaire recom-mandée par le standard ISA-S88 (TR-88). Ce projet propose un modèle cohérent d'utilisation et d'interconnexion des machines d'assemblage.
Objectif
Dans l'industrie pharmaceutique, les systèmes les plus demandés sont Rockwell et Siemens.
o But La SW_Platform définit 1 guide de conception pour 2 PLC afin qu'1 seul HMI suffise à les interfacer.
o Besoins En plus du HMI unique, il faut garder 3 fondamentaux à l'esprit:
Standard & Références (State of the Art). versus ISA-S88, ISA-TR88.02 et ISO-13849
Bonne Pratiques d'Automation. avec spécifications, tests et validations
Développement Rapide d'Applications. "Time is money", "Ready early", ...
Aucun d'entre eux n'est facile à mettre en oeuvre.
Pistes E2ASY
Après divers tests de performances, analyse des prix de revient et études des dernières normes, les 5 pistes suivantes semblent offrir les moyens d'atteindre les 3 cibles précédemment citées.
o Emulation pour un de-risking anticipé & un mode sans-échec de reprise automatique
Pour pré-tester et consolider le séquençage des processus.
o Efficience pour le diagnostique avancé
OEE temps-réel détaillée pour chaque élément offrant diagnostique et maintenance préventive.
o Orienté Agilité
Par la combinaison de spécialisations et d'agrégations flexibles, "lego mindstorm"
o Privilégier la Simplicité
Pour coder plus vite des routines plus rapides en réduisant fichiers, données, codes, bugs...
o Yes nous respectons les normes
La compatibilité permet de réutiliser les codes des fournisseurs sans avoir à réinventer la roue.
En résumé cette plateforme est prête en contacts-ladder et en structured-text (2 prototypes PLC sont codés). Elle respecte les règles promues par ISA-TR88. 8 routines réutilisables sont définies (Admin, Prog, Track, Nest, Bin, Num, Cam et Pls) et 3 routines (logic-actuators-alarm) constituent la tâche "Admin". Comparées aux 1200 lignes d'instructions des 60 routines des plateformes actuelles, ces 11 routines élémentaires totalisent une 100taine de lignes permettant un "modular testing" économiquement et techniquement abordable; en testant 3 lignes d'instructions à l'heure, cette plateforme est validée en boîte blanche après 35 hr d'efforts (avec des tests préalablement rédigés).
3 besoins majeurs
o Conformité TR88, 1ier modèle mécatronique pour l'industrie Assembly et Packaging.
o Développement rapide d'applications software, "RAD" pour réduire les coûts.
o Adoption de bonnes pratiques d'automation (Gamp 5).
5 pistes tangibles
o Emulation incluse aux actuateurs pour dé-risquer offline et disposer d'un mode sans échec online.
o OEE temps réel incluse dans chaque module pour l'auto-diagnostique et la maintenance préventive.
o Agilité par recombinaison des 4 actuateurs élémentaires déjà implantée sur PDS, EQW1 et RAI01.
o Simplicité avec 3 routines par station (logic-actuators-motions) et 1 fichier de config par machine.
o Compatibilité avec TR88 et Gamp5 (modes, états, alarmes, data-in, data-out, mnémoniques, etc...)
4 managers élémentaires avec les caractéristiques suivantes
o L'OEE temps réel dans 3 managers (Admin, Track et Nest).
o Gestion des modes de marche et des états (Admin).
o Mode dégradé par sélection des Tracks et Nests.
o Séquenceur synchrone et asynchrone (Prog).
o Part-ID and Shift-Register data monitoring.
o Gestion de recettes multiples (Admin).
o Management de batch (Admin).
o Erreurs consécutives.
o etc...
4 actionneurs élémentaires avec les caractéristiques suivantes:
o La commande manuelle sans aucune programmation additionnelle.
o La quittance d'alarme simple ou double (HMI et/ou Enclosure).
o La safety et l'auto-recovery après quittance opérateur.
o L'OEE temps réel dans les 4 actuateurs.
o L'émulation de la réponse temporelle.
o Le mode sans échec par émulation.
o Le mirroring (en mode sonde).
o etc...
En sus
La génération automatique de "tests cases" et la modélisation du "Contrôle d'activité" (HMI, SCADA, Recipe, Batch, etc...) sont en cours de définition; le fichier de configuration définissant les séquenceurs et les données d'une machine et de ses stations dispose d'une macro qui génère les mnémoniques et les lignes d'instructions directement dans un PLC Rockwell; c'est d'ailleurs ce même fichier qui contient les informations nécessaires au volet spécifique d'une SDS machine. Pour conclure en adjoignant le rapport d'analyse des coûts software sur les plateformes actuelles, Komax pourrait envisager une réduction des coûts de développement software de 30 à 40% tout en étant réellement "médical".