Inteface requirements and specifications for units, PackML for unit supplyer

PackML - Agenda  What is the problem to be solved?  Why standardize interface?  How is the solution?  Organizational  Technical  Demands to unit supplier  Specification  Test  Other devices  SafePLC and E-Stop  Scale and Printer

3 What is the problem to be solved? Unit suppliers System integrator Dairy Problem – Interfaces 1)Vertically (Unit to supervisory control system) 2)Horisontal (unit to unit)

4 Why standardize interface to units? Easier coupling units in a line Easier deployment of job data Easier detection of warnings and errors Better supervisory control and data acquisition Standardized measurements of OEE Define “best practice” Easier ways to change control on units, supervisory control and MES. Common data interface and I/O interface to all units Common commands, states, modes, eventID, warning & errors Reduce system and interface complexity (technically and organizationally) Unit Line Controller MES SAP CAPEX: Reduces develoment time and cost OPEX: Improve OEE and reduce maintenance cost PackML

5 How is the solution? - Technical One Interface State Model Definition of a Unit The control of a line an units Digital I/O for synchronization of units The Interface State Model Control Commands Unit Control modes Data requirements for OEE calculation

6 How is the solution? - Technical: One Interface State Model

7 How is the solution? - Technical: Definition of a Unit

8 How is the solution? - Technical: The control of a line an units The data types are: Job data (Recipe and Unit Parameter) Command Unit State Unit Mode Warning & Errors OEE data Additional data The physical I/Os: Used for fast control and synchronization of units in the line

9 How is the solution? - Technical: Digital I/O for synchronization of units Infeed Ready Downstream Ready Comments 11The unit(N) is ready to produce - Execute. 10The unit(N) is ready to produce, but the downstream unit(N+1) is not ready to receive products. The unit(N) is only able to produce until the internal buffers are full. Hereafter, the unit(N) will move to the SUSPENDED state. 01The unit(N) is not ready to produce. The downstream unit(N+1) are ready to receive products. The reason for the non ready unit(N) can be that the unit isn’t started, the units is moved to HELD state, STOPPED state or COMPLETE state 00Either the unit(N) or the downstream unit(N+1) aren’t ready to produce.

10 How is the solution? - Technical: The Interface State Model

11 How is the solution? - Technical: The Interface State Model ColorDescription GreenDual State - The Unit is in a stable acting state - Unit is producing. BlueWait State – A stable state used to identify that a Unit has achieved a defined set of conditions. In such a state the Unit is holding or maintaining a status until transitioning to an Acting state (White color). The unit is powered and stationary. WhiteActing State – A state which represents some processing activity e.g. ramping up speed. It implies the single or repeated execution of processing steps in a logica order, for a finite time or until a specific condition has been reached, e.g. Starting is checking the quality af the received data, before raping up speed for execution. RedWait state – A state which represents an error state on the Unit. In this state the Unit is not producing, until the operator have managed to make a transition to the EXECUTING state. The state holds the unit operations while material blockage are cleared, or safe correction of an equipment fault before the production may be resumed. OrangeWait State – A state which represents an error state on the line and the Unit is running at a relevant set point speed, but there is no product being produced while the unit is waiting for external process conditions to return to normal. The unit will also enter this state if the operator want to have a break.

12 How is the solution? - Technical: The Interface State Model

13 How is the solution? - Technical: Control Commands

14 How is the solution? - Technical: PackML State model implementation Unit Control Modes Description PackML State Model implementation (Mandatory / Optional) UndefinedInitialization of Unit when power up. No ProducingThe Unit executes relevant logic in response to commands which are mainly coming from line controller, or entered directly by the operator. Mandatory MaintenanceThis mode allows authorized personnel to run the Unit independent of other Units in the production line. This mode would typically be used for faultfinding, machine trials, or testing operational improvements. Fx. Cleaning a print head is maintenance. Optional ManualThis provides an operator to directly control of individual Unit modules. This feature will be used for the commissioning of the Unit for testing and synchronization of drivers, to set up Unit specific parameters. Optional CleanClean the Unit.Optional JogStep through a process.Optional CIPCleaning in Process (CIP).Optional ….. Optional

15 How is the solution? - Technical: Data requirements for OEE calculation Unit only send OEE data to the line controller. OEE calculation off KPI etc. is not a part of the unit. OEE data to be send contains : EventID Detailed error info Product counters Line Controller OEE Data OEE calculation

16 How is the solution? - Technical: Data requirements for OEE calculation

17 How is the solution? - Technical: Data requirements for OEE calculation OEE and product counters: The counters must be reset with a new recipe. The counter is reset in the resetting state. The reset proces is issued by a Reset command.

18 Demands to unit supplier - Specifications Software Design Specification (SDS) Communication topology Standard communication data Handshake Mode and State Command Unit specific communication data Job data Warning and error OEE data Additional data SDS Template, and SDS examples

19 Demands to unit supplier - Test Test requirements PackML Factory Acceptance Test PackML I/O test PackML Site Acceptance Testing PackML Take Over Certificate Test Suitcase for Factory Acceptance Test

20 Demands to unit supplier - Specifications test: Communication topology Unit specific

21 Demands to unit supplier - Specifications & test: Standard communication data

22 Demands to unit supplier - Specifications & test: Standard communication data Addr. DescriptionData format Value range UnitData length 0.0Not usedByte0-11 Byte 1.0Not usedByte0-11 Byte 2.0Heart Beat Unit Increment frequency 2 Hz INT Bytes DB100 Unit write Addr. DescriptionData format Value range UnitData length 0.0Not usedByte0-11 Byte 1.0Not usedByte0-11 Byte 2.0Heart Beat Line Controller Increment frequency 2 Hz INT Bytes DB106 Line Controller write Data Block “Heart Beat”

23 Demands to unit supplier - Specifications & test: Standard communication data Data Block “Mode” and “State” DB101 Unit write Addr.DescriptionData format Value range UnitData length 0.0Status UnitByte0-11 Byte 1.0Status Line ControllerByte0-11 Byte 2.0ModeINT1-322 Bytes 4.0StateINT1-172 Bytes

24 Demands to unit supplier - Specifications & test: Standard communication data DB107 Line Controller write Data Block “Command”

25 Demands to unit supplier - Specifications & test: Unit specific communication data Data Block “Job data” (Recipe and Unit Parameter) DB102 Unit write (download)/ DB108 Line controller write (upload)

26 Demands to unit supplier - Specifications & test: Unit specific communication data Data Block “Warning & Error DB 104 Unit write

27 Demands to unit supplier - Specifications & test: Unit specific communication data Data Block “Warning & Error Warning Error

28 Demands to unit supplier - Specifications & test: Unit specific communication data Data Block “OEE data” DB 103 Unit write Addr. DescriptionData format Value rangeUnitData length 0.0Status UnitByte0-11 Byte 1.0Status Line ControllerByte0-11 Byte 2.0EventIDINTXXX2 Bytes 4.0Detail Error Info (First error) INTXXX2 Bytes 6.0Good product counterDINT1 – pcs4 Bytes 10.0Rejected portions counter DINT1 – pcs4 Bytes

29 Demands to unit supplier - Specifications & test: Unit specific communication data Data Block “Additional data” (f.x. Unit to unit data) DB105 Unit write DB109 Line controller write

30 Demands to unit supplier - Specifications & test: PackML Factory Acceptance Test PackML Factory Acceptance Test The purpose of this test is to test the interface data blocks and the I/O signals are working correctly and the physical Unit response to the exchanged information and commands. Reference is made to the Agreement. The test will take place at the seller and buyer provides a test case available that can act Line Controller and test the unit communication, state model, eventIDs and data structures. The test is carried out in order to verify that the data blocks can be exchanged between the Unit and the Line Controller. Furthermore, the content of the data blocks needs to be tested. It is warnings, errors, job data, and OEE data. The test will also include the control of the Unit from the Line Controller and the response from the Unit when an error occurs. For example open a door, send information about Held state and the OEE EventID. All relevant seller personnel must be present during the test. The Software engineer and the architect of the Unit must be present during the test. A software engineer appointed by the Buyer might be part of the test.

31 Demands to unit supplier - Specifications & test: PackML I/O test PackML I/O test The I/O test will take place at the Place of Installation, and the purpose is to control that the wiring is done correctly between the Unit and the Line Controller. It might include control signals, Infeed ready, and downstream ready. The E-stop Is to be tested separately. The buyer appoints a software engineer that will describe the results in a test report.

32 Demands to unit supplier - Specifications & test: PackML Site Acceptance Testing PackML Site Acceptance Testing The Site Acceptance Test is to verify that the Unit can run according to the defined performance criteria - Reference is made to the Agreement. It includes a full test of interface, the mapping and PackML states and OEE EventIDs, the exchange of warning and error information. The calculation of OEE figures will be tested. For the seller, the software engineer must be present during the test. The buyer must appoint a software engineer for PLC applications and a software engineer for MES applications for the test. The appoint software engineer for PLC applications must prepare a test report. Such test reports must be approved by the Buyer.

33 Demands to unit supplier - Specifications & test: Test suitcase for Factory Acceptance Test Test Suitcase for Factory Acceptance Test At the Factory Acceptance Test Arla Foods provides a test suitcase. The test suitcase act like a Line Controller. All communication data from the packML interface can be simulated from the test suitcase.

34 Demands to unit supplier - Specifications & test: Test suitcase for Factory Acceptance Test Test step, from Test suitcase : Start Unit from LC (Test State & Event ID) Suspend Unit Starvation (local Suspend test State & Event ID) Unsuspend Unit Starvation (local Suspend test State & Event ID) Suspend Unit Saturation (local Saturation test State & Event ID) Unsuspend Unit Saturation (local Saturation test State & Event ID) Suspend Unit from LC (LC Suspend test State & Event ID) Unuspend Unit from LC (LC Suspend test State & Event ID) Hold Unit (local Hold test State, Event ID & Detailed error info) UnHold Unit (local Hold test State, Event ID & Detailed error info) Complete Unit (Unit Complete test State & Event ID) Job data upload (test upload Job data according to spec.) Job data download (test download af job data) Reset Unit on unit itself (Test State & Event ID) Stop Unit from LC (Test State & Event ID). Check from different states EXECUTE, HELD, SUSPENDED, IDLE and COMPLETE. Start Unit from LC (Invalid Job data test State, Event ID & Detailed error info) Abort Unit (Test State & Event ID)

35 Other Devices - SafePLC and E-Stop

36 Other Devices - Scale and Printer

37 Questions ?