Table 332 contains the functions, macros, timers and variables used by CTLSM and their arguments and their descriptions.
Table 332 – Functions, Macros, Timers and Variables used by CTLSM
Name Type Function/Meaning
CheckResponseBlocks Function This local function checks whether the syntax and the semantics of the response is correct
ParameterToSend Function This local function indicates the existence of any parameter record AdaptConfiguration Function This local function adapts the list of parameter records according to
the connect response
SumARinData Function This local function is issued from DEVSM if all consumer reaches the state Data
StoredSessionKey Variable This local variable stores the session key from the connect service SetConnectRequestData Function This local function configures the connect request
PrepareWritePDU Function This local function fetches the parameter from the local data base and constructs the write multiple PDU
Application characteristics 7.6
Device ident number 7.6.1
The Device Ident Number is necessary for all IO devices. For each type of device an individual Device Ident Number will be needed. This Device Ident Number is not a series number. If a manufacturer has a Device Ident Number for one type of device it is allowed to use this number for all produced devices of the same type. At devices of the same type but with differences in the amount of inputs and outputs it is possible to use the same Device Ident Number for each produced IO Device.
Each device type shall have an individual Device Ident Number which is part of the object UUID.
The Device Ident Number consists of a Vendor ID, which is a globally organizational administered number, and a Device ID, which is administered by the manufacturer.
Network topology 7.6.2
IO controller and IO devices make provisions concerning the network connection. The DTEs of such devices shall support a bit rate of 100 MBit/s in full duplex mode. However, some topologies include e.g. wireless segments which do not fulfill these requirements. In such case, the wireless part shall be connected in such a way that only application relationships that use these network path suffer under lower performance. The adaptation can be done by means of the attribute reduction ratio. An example is depicted in Figure 59.
Mandatory 100 Mbit/s Full duplex
Mandatory 100 Mbit/s Full duplex
Alternative:
e.g. wireless 10 Mbit/s Half duplex
IO controller manageable Switch IO device
with VLAN Priorities manageable Switch
with VLAN Priorities
Wireless Bridge Wireless Bridge
Parameter of this AR consider the slower wireless link
Figure 59 – Example of network topology including slower wireless segments Figure 60 shows an example closing a line with wireless modules for media redundancy. The shown topology is applicable if the timing required by the application process can be fulfilled.
Alternative topology for media redundancy:
e.g. wireless 10 Mbit/s Half duplex
IO controller IO device
Wireless Bridge Wireless Bridge
IO device IO device
IO device
Figure 60 – Example of media redundancy including wireless segments Summary of FAL services
7.7
IO Device 7.7.1
Table 333 contains the FAL services of the IO device.
Table 333 – FAL services of the IO device
Services req ind rsp cnf
Alarm x x x x
Application Ready x — — x
Connect — x x —
Prm End — x x —
Prm Begin — x x —
Read — x x —
Write — x x —
Local Add Diagnosis Entry x — — x
Local AR Abort x x — x
Local AR In Data — x — —
Local Create LogBook Entry — x — —
Local Data State Changed — x — —
Local Diagnosis Event — x — —
Local Get Input IOCS x — — x
Local Get Output x — — x
Local Get Time x — — x
Local New Output — x — —
Local Remove Diagnosis Entry x — — x
Local Set AR State x — — x
Local Set Command — x x —
Local Set Input x — — x
Local Set Output IOCS x — — x
Local Set Provider State x — — x
Local Set Redundancy x — — x
Local Set State x — — x
Local Set Time x — — x
Local Sync State Info — x — —
Local SYNCH Event — x — —
Local Time State Info — x — —
IO Controller 7.7.2
Table 334 contains the FAL services of the IO controller.
Table 334 – FAL services of the IO controller
Services req ind rsp cnf
Alarm x x x x
Application Ready — x x —
Connect x — — x
Prm End x — — x
Prm Begin x — — x
Read x x x x
Write x x x x
Services req ind rsp cnf
Local AR Abort x x — x
Local AR In Data — x — —
Local Create LogBook Entry — x — —
Local Data State Changed — x — —
Local Diagnosis Event — x — —
Local Get Input x — — x
Local Get Output IOCS x — — x
Local Get Time x — — x
Local New Input — x — —
Local Set AR State x — — x
Local Set Command — x x —
Local Set Input IOCS x — — x
Local Set Output x — — x
Local Set Provider State x — — x
Local Set Redundancy x — — x
Local Set State x — — x
Local Set Time x — — x
Local Sync State Info — x — —
Local SYNCH Event — x — —
Local Time State Info — x — —
IO Supervisor 7.7.3
See 7.7.2.
Annex A (informative) Device instances
The design and construction of physical automation devices is beyond the scope of this specification and therefore vendor specific. However, it provides a model for physical devices to host one or more IO controller or IO devices. These particular IO controller or IO devices are referred to as instances. The physical device is characterized by its device address which is a unique IP specification address assigned to a network interface. The further addressing is provided by means of the underlying connectionless protocol according to Publication C706 of the Open Group. These means are:
– Interface UUID – Object UUID
The model is provided in Figure A.1. It covers the IO controller and IO device. The gray boxes in Figure A.1 are beyond the scope of this service definition.
NOTE 1 The term “Interface” is used according to Publication C706 of the Open Group. An interface represents a collection of functions or services that can be called by a remote user.
Ethernet interface with unique name
Ethernet
IO Device Interface IO Controller
Interface
Interface UUID
Physical Device
Object UUID
End PointRPC Mapper (epmap)
Other Interfaces, Protocols, Applicationsor Object UUID
Node 1 Node x
Ethernet interface with unique name
NameOfStation 1 NameOfStation n
NameOfPort 1
NameOfPort y
SNMP(MIBs)
LLDP
Port Port Port
NameOfPort 1 NameOfPort x
IO Device
ControllerIO IO
Controller IO Device
Port
KeyNameOfDeviceis the unique name of the chassis NameOfStationis the unique name of the interface NameOfPort is the unique name of the port LLDP_ChassisID =
NameOfDevice LLDP_PortID =
NameOfPort + NameOfStation NameOfDevice = LLDP_ChassisID
Figure A.1 – Instance model
The Interface UUID provides a means to address an IO supervisor, an IO controller, or an IO device without further configuration. The following Interface UUIDs are defined in 5.3.1.6.1:
– IO Device Interface UUID – IO Controller Interface UUID – IO Supervisor Interface UUID
– IO Parameter Server Interface UUID
Furthermore, the epmap interface UUID shall be supported by all IO device classes.
The Object UUID provides a means to address the instance of the IO supervisor, IO controller, IO parameter server, or IO device.
The connectionless DCE RPC protocol according to Publication C706 of the Open Group defines a local instance referred to as End Point Mapper (epmap). The End Point Mapper receives any incoming RPC request at TCP/UDP and transfers the request to the matching interface and object. Therefore, each server has to register its UUIDs before. This information includes:
– Interface with its UUID, Major Version, Minor Version – Object UUID
– Binding Information such as protocol (UDP/TCP), server IP address, port, 64 octets annotation
NOTE The GSD contains the information about the maximum number of instances a device supports.
Annex B (informative)
Components of an Ethernet interface
The design and construction of physical devices is beyond the scope of this specification and therefore vendor specific. However, an Ethernet interface needs a sum of components:
– RJ45 female connector – Magnetics
– PHY – MAC – àController – RAM – ROM
A scheme of components is provided in Figure B.1 and Figure B.2. The gray boxes in Figure B.1 are beyond the scope of this service definition.
ROM àController RAM
MAC
Ethernet Magnetics
Stamping
PHY
RJ45
Figure B.1 – Scheme of an Ethernet interface
With the ability for bridging, the structure of the Ethernet interface changes. Figure B.2 shows the new scheme.
ROM àController RAM
NoteMore than two ports possible
Bridge
MAC
Magnetics Stamping
PHY
RJ45
MAC
Magnetics Stamping
PHY
RJ45
Ethernet Ethernet
. . .
Figure B.2 – Scheme of an Ethernet interface with bridging ability
Figure B.3 shows the scheme using optical media.
ROM àController RAM
NoteMore than two ports possible
Bridge
MAC
Stamping
PHY
Jack
MAC
Optical transceiver
Stamping
PHY
Jack
Ethernet Ethernet
. . .
Optical transceiver
Figure B.3 – Scheme of an Ethernet interface with optical ports Figure B.4 shows the scheme using radio communication.
ROM àController RAM
Bridge
MAC
Magnetics PHY
RJ45
MAC
Magnetics Stamping
PHY
RJ45
Ethernet Ethernet
. . . MAC
Transmitter Receiver
RF Switch
RF Filter Stamping
Figure B.4 – Scheme of an Ethernet interface with bridging ability using radio communication
Figure B.5 shows the scheme using radio communication.
ROM àController RAM
MAC
Transmitter Receiver
RF Switch
RF Filter
Figure B.5 – Scheme of an Ethernet interface with radio communication
Annex C (informative)
Scheme of MAC address assignment
Figure C.1 shows the scheme of MAC address assignment according to IEEE 802.1D
ROM
. . .
Interface MAC address
àController RAM
MAC
Ethernet Port 001 Port MAC address
MAC
Ethernet Port n
Port MAC address MAC
Bridge
Figure C.1 – Scheme of MAC address assignment
Annex D (informative) Collection of objects
The objects of an IO device can be read using the read record service and the predefined filters addressed by the record indices. The IO device builds the intersection and search for available objects.
The size of the intersection depends on the AR type, the record index and the IO device. For the implicit AR and the IOS AR for DeviceAccess the intersection is only depending on the record index and the IO device. For an IO AR it also depends on the selected submodules of the AR.
Example Figure D.1 shows the intersection of objects for a read record service with a slot specific index from an IO controller using an IO AR. In this case the IO device should use the “green” intersection to search for e.g.
“Diagnosis in channel coding” and send the available data in the read record response.
IO device slot
AR
Sum of objects of an IO device Sum of objects of a slot of an IO device Sum of objects of an IOC or an IOS AR Intersection of IO device, slot, and AR
Figure D.1 – Example for an intersection of IO device, slot, and AR
Annex E (informative)
Measurement of the fast startup time
For the comparison of devices the definition of the measurement of the fast startup time is necessary. Figure E.1 shows the reference model for this measurement.
IO controller IO device
Enable power of the IO device
„Power on“
Establishing of an AR
(IODConnect, WriteRecord, ParametrizationEnd, ApplicationReady, Data)
Fast startup time
Set the outputs the first time to the requested value E.g. „Open retaining clip“
Figure E.1 – Measurement of the fast startup time
Annex F (informative)
Dynamic Frame Packing
An RT Frame is structured according to Figure F.1. The frame itself is encapsulated for Ethernet according to IETF RFC 894 by using the elements destination address, source address, ether type and CRC.
If priority tagging according to IEEE 802.1Q is used, the ether type is set to 0x8100, a priority / VLAN field is following, followed by a second ether type set to 0x8892 indicating an RT frame.
The content of the RT frame are the elements Frame ID, C_SDU and APDU Status.
Destination addr 6 Byte
Source addr 6 Byte Ethertype 2 Byte Priority / VLAN 2 Byte Ethertype 2 Byte Frame ID 2 Byte C_SDU 40 - 1440 Byte APDU Status 4 Byte CRC 4 Byte
Ethernet Encapsulation according to RFC 894 Priority Tagging according to IEEE 802.1Q (optional) RT Frame according to IEC 61158-6-10
Figure F.1 – Frame Layout
The Frame ID is used to indicate the frame itself, the C_SDU to transport the content of IOCRs (i.e. IO Data, IOXS) and the APDU Status indicates the status of the frame.
The C_SDU may be structured such that it either carries the content of exactly one IOCR or that it carries the content of multiple IOCRs. In the latter case a sub-part of the C_SDU (called sub frame) carries the content of a particular IOCR; the frame is then sub-structured into sub frames.
The reason for using sub-structured frames is minimizing bandwidth and in consequence optimizing performance. As Figure F.1 shows, the overhead of a frame, i.e. the bytes to be transported besides the C_SDU, amounts to 28 bytes; however since InterFrameGap (12 bytes), Preamble (7 bytes) and Sync (1 byte) have additionally to be taken into account, the overhead of a frame sums up to 48 bytes (or 42 bytes if the preamble is shortened). If the C_SDU is in addition smaller than 40 bytes, the delta has to be added additionally.
Thus one can easily see that using sub-structured frames will reduce the bandwidth needed by combining sub-frames, since as shown in Figure F.2 the overhead for a sub frame amounts to 6 bytes. On combining multiple sub frames in one frame the overhead for the frame is only paid once.
SFPosition SFDataLength SFCycleCounter Data Status SFCRCC_SDU 1 - 255 Byte
SFCRC SFPosition = 0 SFDataLength = 0
Subframe
SFPosition SFDataLength SFCycleCounter Data Status SFCRCC_SDU 1 - 255 Byte
Subframe
…
Frame ID APDU Status
Termination
Figure F.2 – Sub frame Layout
Each of the sub frames has a position number (SFPosition), a data length describing the length of the C_SDU (SFDataLength), a cycle counter (SFCycleCounter), a data status (DataStatus), the frame’s data itself (C_SDU) and a CRC for the sub frame (SFCRC).
The position number starts with 1 and increases with every sub frame by 1 (the second sub frame thus carries the position number 2 and so on). The list of sub frames is terminated by a special sub frame having the position number 0.
The data status of a sub frame indicates its data status. The data status within the frame’s APDU status indicates the frame’s data status. If the frame consists of sub frames, the frame’s data status can be safely ignored. It is feasible to set the frame’s data status to a static value (e.g. DataValid = valid, ProviderState = Run, ProblemIndicator = Normal Operation, SubframeSenderMode = 0x00, Ignore = 0x01…).
Each of the sub frames is from an applications point of view comparable to a complete frame, since it has a local APDU Status (i.e. cycle counter and data status) and a local C_SDU (for IO data and IOXS). It is however restricted in the maximum size of the C_SDU; the maximum is 255 bytes (compare to a complete frame; there the maximum is 1 440 bytes).
Sub-structured frames are built in two ways:
Dynamic Frame Packing
The sub-structured frame will be built by a chain of adjacent IO devices.
Up to 63 sub frames are supported in a dynamically packed frame.
End to End
The sub-structured frame will be packed completely by one IO device. A possible use case is for example a Multi-IO device (e.g. a device hosting multiple IO device instances), where the IOCRs to the multiple instances are packed together by this IO device. Another use case is for example a device used for integration of another fieldbus (e.g. gateway).
Here the IOCRs to the subordinated fieldbus devices are packed together by having one sub frame per subordinated IO device.
Up to 127 sub frames are supported in such an end to end frame.
End to End may be used for input and output data as shown in Figure F.3.
IOC
H T
IOD IOD IOD IOD
T H
Output
Input H
T
Ethernet Header Ethernet Trailer
Figure F.3 – End to End
The dynamic frame packing may be used for input and output data as shown in Figure F.4.
IOC
H T
IOD IOD IOD IOD
T H
Output
Input H
T
Ethernet Header Ethernet Trailer
Figure F.4 – Dynamic frame packing
As an additional optimization the output frame (Provider from the IO controller point of view) shall be truncated as shown in Figure F.5.
IOC
H T
IOD1 IOD2 IOD3 IOD4
Output
H T
Ethernet Header Ethernet
Trailer
T H
1
T H
2
T H
3 Generates
Generates
Generates
Figure F.5 – Dynamic frame packing – Truncation of outputs
Every IO device is triggered “downstream” (as seen by the IO controller) through the frame as indicated by the frame ID or additionally by the MC fast forwarding address. While receiving the frame on one port, the IO device propagates the frame downstream on the appropriate port. The frame propagated downstream is shortened by cutting the frame at the sub frame position dedicated to this IO device and appending a new Ethernet trailer with an updated CRC computed for the shortened frame. The sub frame dedicated to this IO device is received locally.
Figure F.6 shows outbound packing from its timing behavior.
Ethernet Header Subframe 4
Subframe 3
Subframe 2 Subframe 1 Ethernet Trailer
Ethernet Header Subframe 4
Subframe 3
Subframe 2 Ethernet Trailer
Ethernet Header Subframe 4
Subframe 3 Ethernet Trailer
Ethernet Header Subframe 4 Ethernet Trailer
IOD1 IOD2 IOD4 IOD4
IOC
Figure F.6 – Dynamic frame packing – Outbound Pack
It is easily to see that the particular sub frames are received by the IO devices downstream at almost the same time.
The input frame (Consumer from the IO controller point of view) shall be concatenated as shown in Figure F.7 for optimization.
IOC
IOD1 IOD2 IOD3 IOD4
T
4
H
4
Input
H T
Ethernet Header Ethernet
Trailer
T
3
H
3
T
2
H
2
T
1
H
1
Generates
Generates
Generates
Generates
Generates
Generates
Generates Generates
Figure F.7 – Dynamic frame packing – Concatenation of inputs
Every IO device has a locally defined start time to issue the input frame. While sending the frame on the appropriate upstream port, the IO device awaits receiving the frame of the IO device downstream on the other port (indicated by Frame ID or additionally by the MC fast forwarding address). The header and trailer of the received frame are dropped and the received sub frame(s) are appended at the appropriate sub frame position. Then an Ethernet trailer with CRC computed for the complete frame content is appended.
Since all IO devices start sending more or less at the same time, IOD3 appends for example the sub frame of IOD4, IOD2 the sub frames of IOD3 and IOD4 (having been concatenated by IOD3), IOD1 the sub frames of IOD2, IOD3 and IOD4 (having been concatenated by IOD2).
Since the Ethernet header of an IO device (e.g. H1 of IOD4) is removed in the next IO device upstream (e.g. IOD3) the time needed to send the header bytes from IOD4 to IOD3 can be optimized. It is sufficient, when the first byte of the sub frame data is available in the IO device, after the H2 of IOD3 and the sub-frame data related to IOD3 has been sent already. In this case the sub frame data of IOD4 can be docked “on the fly” to the frame currently leaving IOD3. This applies similar to IOD1 and IOD2.
Figure F.8 shows inbound packing from its timing behavior.
Ethernet Header Subframe 1
Subframe 2
Subframe 3
Subframe 4 Ethernet Trailer
IOD1 IOD2 IOD4 IOD4
IOC
Ethernet Header
Subframe 2
Subframe 3
Subframe 4 Ethernet Trailer
Ethernet Header Subframe 3
Subframe 4 Ethernet Trailer
Ethernet Header
Subframe 4 Ethernet Trailer
Figure F.8 – Dynamic frame packing – Inbound Pack
The Frame Send Offset of the particular frames is computable by using the following means:
The first byte of the header of some IO device (e.g. IOD4) will appear after LineDelay + local Bridge Delay in the IO device upstream (e.g. IOD3). Thus time needed to send the own sub frame (e.g. the sub frame of IOD3) has to compensate LineDelay + local BridgeDelay + Frame Send Offset.
This leads to the following formula:
left right
to left
subframe
right Length * 80 ns FrameSendOffset LineDelay BridgeDelay
ffset
FrameSendO + ≥ + +
(F.1)
where
FrameSendOffsetright is the frame send offsett right
Lengthsubframe is the length of sub frame
FrameSendOffsetleft is the frame send offsett left LineDelayto right is the line delay to right BridgeDelayleft is the bridge delay left
NOTE 1 Be aware, that if the Preamble is adjusted differently through the DFP group, the formulas have to be adjusted.
If one wants to have the same Frame Send Offset (e.g. 0) through the DFP group, the formula can be transformed to
ns 80
y BridgeDela LineDelay
Lengthsubframe toright+ left
≥ (F.2)
where
Lengthsubframe is the length of sub frame LineDelayto right is the line delay to right BridgeDelayleft is the bridge delay left
NOTE 2 As a hypothetical sample take for LineDelay 500 ns and for BridgeDelay 600 ns. Then the length of the sub frame has to be greater or equal to 14 bytes. Note that the sub frame definition allows GAP (i.e. empty space at the end of the sub frame). Thus IO devices with less IO data can be compensated by adding a GAP.
Every IO device has a locally defined start time to issue the input frame. While sending the frame on the appropriate upstream port, the IO device awaits receiving the frame of the IO