Industrial Control Engineering UNICOS device and front-end Hervé Milcent UNICOS device front-endHervé Milcent1

Industrial Control Engineering Outline  Accelerator context  WinCCOA (PVSS) constraints  Why device and front-end  Network protocol in accelerator  UNICOS requirement  UNICOS choice  Front-end & device  Example of device and front-end  Widget/faceplate/action  UNICOS Limitations UNICOS device front-end2Hervé Milcent

Industrial Control Engineering Accelerator context  Data are time stamped at the source: where the data are read  CRYO: PLC synchronized by NTP or manually  QPS: WorldFIP agent synchronized by the LHC timing via the FEC  CIET: FEC  CMW Server  ‘Fake’ time stamp must not be added: ex. time stamp generated by WinCC OA UNICOS device front-endHervé Milcent3

Industrial Control Engineering WinCC OA (PVSS) 3.8-SP2 behavior 1. Invalid time stamp: time stamp in the past compared to the current time, the DPE time stamp will be a ‘fake’ one 2. A driver setting invalid bit, the DPE time is the time of setting the invalidity. 3. Data archived with last_val disabled, if the archive is re- activated (not always), a data is archived with time=the time when was disabled last_val  UNICOS:  For 1.: accepted in all projects except for QPS where the data are rejected by the CMW driver (special extension), however the UNICOS TSPP protocol never gives data in the past.  For 3.: no solution, need a fix from ETM.  2. is disabled for all drivers (DIP is not a driver). The invalid bit are never set except at creation time and when explicitly set in PARA (PARA is never used by the operator). UNICOS device front-endHervé Milcent4

Industrial Control Engineering Network protocol in accelerator  Time stamp and push protocol from the publisher  The publisher pushes the data whenever it wants  It gives a time stamp together with the data  No data:  Could mean no new data  Publisher not working  Work process in the publisher not working  WinCC OA driver not connected to the publisher  In some case, the entity reading the data may be in bad state, but the device is available:  FESA RT task stopped, FESA CMW server still running  PLC in stop mode, ping to PLC still ok UNICOS device front-endHervé Milcent5

Industrial Control Engineering UNICOS requirement  At any time, from any view the operator must  Know the validity of the data  Know if the process is working fine  In case of problem be able to diagnose rapidly the source of the problem.  UNICOS common sense:  A data is read by something having processing resource UNICOS device front-endHervé Milcent6

Industrial Control Engineering UNICOS choice  Driver never set the invalid bit  Software entity reading the data:  Provide one extra data changing periodically with a time stamp if possible  This data must reflect the state of the processing  If the process loop is not working: no update of this data  This entity is the front-end  All other data are device  The operator manipulates devices not front-ends  The device knows its front-end, the quality is known  Front-end extra data updated regularly = Ok good comm, no data from device = OK  Front-end extra data not updated regularly = bad comm, unknown data state UNICOS device front-endHervé Milcent7

Industrial Control Engineering UNICOS front-end & device  A device is a piece of data  A front-end is the entity reading that device, the check of the correctness of the comm is done with the systemIntegrity component and the front-end extra data value or timestamp  Device DP = hardware view of the device: where is located/read the device  Classified by device type  Classified by application: this concept is inherited from the CRYO requirement (even before UNICOS in PVSS), like domain and nature  Application=grouping devices of same process type, split in many front-end  E.g.: QPS, all devices of a same powering sub-sector, device in many front- ends  With a number to differentiated them: like a memory address, channel number, WorldFIP bus and addess, this number is unique.  Device name = logical name, name know by the operator, e.g.: CV901, etc.  Device without entity reading it: attached to a SOFT_FE front-end  Front-end DP name: front-endtype-frontendname  Front-end name: logical name UNICOS device front-endHervé Milcent8

Industrial Control Engineering UNICOS front-end & device example  QPS, CIET, SURVEY: 2 separate WorldFIP buses in a FEC  The front-end is the entity reading the WorldFIP bus.  The periodic data is the BA cycle if the process is working fine  because it was more convenient, we could have done it differently  CRYO, PIC, WIC: PLC  The front-end is the PLC  The periodic data is a data updated into the PLC process loop UNICOS device front-endHervé Milcent9

Industrial Control Engineering Hervé’s rule: front-end  Choose the most suitable  Front-end = process entity reading the data  Quality of the device data = front-end quality  Front-end comm bad = bad data quality  Front-end comm good = good data quality  Example front-end:  Data read by an WinCC OA CMW publisher (server)  Front-end = CMW publisher  WinCC OA CMW publisher provides a data periodically updated  Data read by a WinCC OA OPC Server  Front-end = OPC Server  Front-end periodic data: can be a data polled periodically from the OPC Server  Data read by a crate: CAEN crate, POPS front-end, etc.  Front-end = crate, even if through a protocol like OPC Server, CMW  Front-end periodic data: can be a data polled periodically or an internal data from the crate like timestamp. UNICOS device front-endHervé Milcent10

Industrial Control Engineering Hervé’s rule: device  Choose the most suitable  Device = set of meaningful data you want to act on it (read/set)  Example of device:  CPC: AnalogInput = device, the operator manipulate the analog input  CIET: TT = analog input channel = device, the operator manipulate the TT  QPS: WorldFIP agent having many analog input value = device, the operator manipulate the agent. UNICOS device front-endHervé Milcent11

Industrial Control Engineering Widget/faceplate/action  Device and front-end: widget, faceplate, trending  Same mechanism  Front-end less opened than device  Front-end has less feature than device, e.g. no select action on front-end  Action:  Device: fully customizable, customizable at the device type and device level, can be modified online, not hardcoded in panels  Front-end: customizable via the UNICOS file access right, hardcoded in panel via UNICOS file access right UNICOS device front-endHervé Milcent12

Industrial Control Engineering UNICOS limitations  Front-end action: same mechanism as device action, in IS-574  Device action: should be extended in IS-268  Device without front-end  Not seen in the UNICOS utilities and tools  Or seen as not available  Proxy can be used  Should be fixed in IS-538, IS-537  Device DP names must follow the UNICOS naming convention which is different from the JCOP one.  Device DP: hierarchy, front-end-application-devicetype-uniquenumber (like memory number, channel number, WorldFIP bus and number, etc.)  Device name: logical name, CV901  Front-end DP name: front-endtype-frontendname  Front-end name: logical name  Trending  JCOP: DPE alias or DPE name  UNICOS:  based on alias and a DPE  Could be ‘a la’ JCOP if we set alias on DPE: will be tested in LHC_GCS UNICOS device front-endHervé Milcent13

Industrial Control Engineering How do I define device and front-end type?  List the possible front-end, devices, hierarchy  List of all the requirements  Weight them  And decide what is the most appropriate.  This will be the implementation at a given time, that can become bad after some years …. UNICOS device front-endHervé Milcent14