Bsi bs en 50325 3 2001

BRITISH STANDARD BS EN 50325 3 2001 Industrial communications subsystem based on ISO 11898 (CAN) for controller device interfaces — Part 3 Smart Distributed System (SDS) The European Standard EN 50325[.]

Definitions

Application Layer

seventh layer of the ISO/OSI Reference Model (see ISO/IEC 7498-1)

Application Layer Protocol (ALP)

rules governing the structure and timing of Application Layer Protocol Data Units that are used to achieve the services provided by the application layer

Application Layer Protocol Data Unit (APDU)

unit of data transfer exchanged between application layers It is encapsulated within a Data Link LayerProtocol Data Unit (DLPDU) when transmitted from one component to another

Application Layer Service

service provided to the Service User of the application layer The service may be provided by means of a specified function call

Autobaud

network process for determining the network communication baud rate

Change Of State (COS)

report that a binary device has changed state

Change Of Value (COV)

report that a device input value has changed by a predetermined amount

Confirm

The Confirm is an Application Layer Primitive service that represents an interaction where a Service Provider indicates the completion of a previously invoked procedure at a specific service access point This notification informs the Service User of the presence of a response, as outlined in ISO TR 8509.

Data Link Layer Protocol Data Unit (DLPDU)

protocol data unit at the data link layer

Embedded Object

network-addressable entity within a Logical Device The Embedded Object may be e.g an embedded interface, an embedded device, an embedded function or an embedded function block

Licensed Copy: :FULLNAME, : DATE, Uncontrolled Copy, (c) BSI

Embedded Object Identifier

The Application Layer Protocol Service Provider communicates that a procedure has been initiated by the Application Layer Protocol Service User at the peer service access point This communication, known as the Indication, serves as an Application Layer Primitive service, alerting the Service User to a request from another device or controller, as outlined in ISO TR 8509.

3.1.13 Logical Device separate addressable entity within a Physical Component A Logical Device is connected to the communications channel via its logical address

3.1.14 Network all the physical media, connectors, associated communication elements and a given set of communicating devices interconnected for the purpose of communication

3.1.15 Object Model description of behaviour and structure that comprises a set of attributes, a set of actions and a set of events

3.1.16 Physical Component single or modular physical package, including hardware and software and containing one or more Logical Devices, that is connected to the Network

3.1.17 Physical Layer Interface PLI interface between the Physical Component and the communications media

3.1.18 Primitive implementation-independent representation of an interaction between a Service User and a Service

Provider Primitive services exist at the Application Layer level The Primitives are: Request, Response, Indication and Confirm (ISO TR 8509)

3.3.1 (+) qualifying suffix used with Result parameter service descriptions As a Result qualifier, it refers to a

Indication

An Application Layer Protocol Service Provider communicates that a procedure has been initiated by the Application Layer Protocol Service User at the peer service access point This communication is known as an Indication, which serves as an Application Layer Primitive service The Indication alerts the Service User about a request from another device or controller, as outlined in ISO TR 8509.

Logical Device

separate addressable entity within a Physical Component A Logical Device is connected to the communications channel via its logical address

Network

all the physical media, connectors, associated communication elements and a given set of communicating devices interconnected for the purpose of communication

Object Model

description of behaviour and structure that comprises a set of attributes, a set of actions and a set of events

Physical Component

single or modular physical package, including hardware and software and containing one or more LogicalDevices, that is connected to the Network

Physical Layer Interface PLI

interface between the Physical Component and the communications media

Primitive

implementation-independent representation of an interaction between a Service User and a Service

Provider Primitive services exist at the Application Layer level The Primitives are: Request, Response,Indication and Confirm (ISO TR 8509)

Abbreviations

Symbols

3.3.1 (+) qualifying suffix used with Result parameter service descriptions As a Result qualifier, it refers to a

3.3.2 (-) qualifying suffix used with Result parameter service descriptions As a Result qualifier, it refers to an unsuccessful result in Service Convention diagrams

3.3.3 (=) qualifying prefix used with Indication and Confirm Primitive service descriptions in Service Convention diagrams It means that the Primitive is the same as one occurring at a previous level

4 Relationship with the OSI Reference Model

The SDS protocol is based on a three-layer architecture.

These layers represent a simplified version of the OSI (Open Systems Interconnection) seven-layer architecture, aligning with the physical, data link, and application layers of the OSI Reference Model (ISO/IEC 7498-1).

The Application Layer uses the services provided by the V2.0A CAN Specification data link layer of

NOTE 2 Figure 2 compares the architecture of the SDS Protocol Model with the OSI Reference Model.

SDS Protocol Model Corresponding ISO Layers

CAN DATA LINK LAYER DATA LINK LAYER

SDS PHYSICAL LAYER PHYSICAL LAYER

Figure 2 - SDS protocol architecture compared with the OSI Reference Model

SDS Network

Network

An SDS Network is made up of various Physical Components, such as input and output devices, PLC interfaces, PC interfaces, and connections to other networks These Physical Components are organized as groups of Logical Devices that interact through a physical medium A logical representation of an SDS Network is illustrated in Figure 3.

Embedded Device Embedded Device Embedded Function Block SDS Address

Logical Device Logical Device Logical Device

Embedded Device Embedded Device Embedded Function Block SDS Address

Logical Device Logical Device Logical Device

Figure 3 - Logical representation of an SDS Network

Modelling

Component models represent SDS network visible structure and behaviour of a node The primary purpose of modelling is to improve the interoperability and interchangeability of SDS components.

The basic SDS component model structure is shown in graphical form in Figure 4 An SDS Physical

A component consists of at least one logical device that connects to the network Each logical device can contain between one and thirty-two SDS embedded objects Additionally, a physical component may include multiple logical devices, each assigned different SDS logical addresses on the network.

OF THE FOLLOWING TYPES: o I/O DEVICES o FUNCTIONS EN 61131-3 o FUNCTION BLOCKS o INTERFACES EACH SDS OBJECT MODEL INCLUDES:

Diagnostic Event End Of Timer Change Of State Change Of Value

NOOP Change Address Clear ALL errors Self Test

Device Type Catalog Listing Vendor Number Software Release Number Date Code

Device Name Tag Name Serial Number

Figure 4 - Graphical representation of Component Model

An SDS Component Model shall include three types of elements: attributes, actions and events These elements describe the behaviour of an SDS Embedded Object.

Attributes serve as containers for data visible on the network, and each device's network variables encompass the collection of attributes defined by its Embedded Objects Each attribute is assigned a primitive tag that identifies its associated data type, along with specifications for data size and/or length Attributes can be categorized as read-only, read-write, or read-write with password protection.

Actions in SDS Embedded Object services are initiated through an action request message that may contain data, functioning similarly to a subroutine call in software programming The corresponding action response message can also include data.

SDS Embedded Object reports are classified as events, which are generated by a device when the trigger condition specified in the SDS Object Model is met These event messages may also contain relevant data.

Hierarchy

NOTE SDS defines a mechanism to organize and manage models These models are separated into major categories and arranged hierarchically.

The standard SDS hierarchy, as illustrated in Figure 5, outlines the SDS Minimum Model, which defines essential features that all devices must support These foundational features are inherited by various models, including I/O Devices and Interface Devices, each of which specifies additional attributes, actions, and events This inheritance continues with subsequent models, which introduce further features, ensuring that each model supports all the features of its parent models.

Figure 5 - SDS example of Models in hierarchical form

The highest level of the hierarchy establishes the foundational structure and essential behavior of the Physical Component and Logical Device within the SDS Model, which is mandatory for all SDS products Each subsequent level in the hierarchy introduces further attributes, actions, and events specific to SDS Embedded Objects Additionally, SDS Embedded Objects at each hierarchical level will inherit all features from the preceding levels.

A Logical Device may contain up to 32 Embedded Objects in any combination.

SDS Application Layer Services

Service conventions

The Application Layer shall provide the services listed in Table 1.

Table 1 - SDS Application Layer Services

Read Allows the ALP service user to read the value of a device attribute.

Write Allows the ALP service user to modify the value of a device attribute.

Event Allows an ALP service user to report an event.

Action Allows an ALP service user to command a device to execute an action.

The Change Of State–ON service reports when a binary device transitions to the ON condition, while the Change Of State–OFF service indicates a transition to the OFF condition Additionally, the Write State–ON service allows users to set a binary output device to the ON state, and the Write State–OFF service enables setting the device to the OFF state.

The SDS Service Model employs four fundamental functions—Request, Response, Indication, and Confirm—to deliver Application Layer Services at the CAN Data Link Layer These primitives are illustrated in Figure 6 for standard service and in Figure 7 for fragmented service.

CAN Data Link Layer Physical Layer

Figure 6 - Representation of the service Primitives (without fragmentation)

The service sequence illustrated in Figure 6 begins when a sender activates the application layer "Read" service This action triggers a Request Primitive at the Application Layer, leading to the generation of an Application Layer response.

The initiating device sends a Protocol Data Unit (PDU) to the responding device, which triggers an indication of the received message for the Service User In response, the Service User at the responding device generates a Response Primitive that leads to the creation of an Application Layer Protocol Data Unit (APDU) Upon receiving this APDU response, the initiating device delivers a Confirm Primitive to its Service User.

CAN Data Link Layer Physical Layer

Request APDU (1st fragment) Request APDU (2nd fragment) Request APDU (nth fragment)

Figure 7 - Representation of the service Primitives with fragmentation

The Fragmented Service is used for information that exceeds the maximum data length of a single

The Application Layer Protocol Data Unit (APDU) process begins when a Request Primitive is sent to the Application Layer, leading to the creation of fragmented APDUs by the initiating device Once the responding device receives the final APDU fragment, it triggers an Indication of the received message for the Service User Subsequently, upon receiving the Indication Primitive, the Service User at the responding device takes action based on the received information.

The Response Primitive on the Application Layer generates a Response APDU, which is then received by the initiating device This triggers a Confirm Primitive to be sent to the Service User at the initiating device.

Read service

This service is designed to read the attribute value of an Embedded Object, such as obtaining the current value from a sensor The parameters for the read service are detailed in Table 2.

Table 2 - Parameters defined for read service

Parameter Request Indication Response Confirm

EOID Mandatory (=) Request received Mandatory

Attribute ID Mandatory (=) Request received Mandatory

Conditional Mandatory Mandatory (=) Response received

The parameters in the response serve specific functions: the Logical Address identifies the device from which attribute data is read, and it is mandatory in both the Request and Response The EOID (Embedded Object ID) indicates which Embedded Object is to be read, also required in both cases The Attribute ID specifies the attribute to be read, with its value defined in the Object Model of the Embedded Object, making it mandatory for both Request and Response If the read is successful, the Result (+) parameter is returned, including the attribute ID and the value read Conversely, if the read fails, the Result (–) parameter is provided, which includes the attribute ID and an error code explaining the failure reason.

Write service

This service is designed to modify attributes of an Embedded Object, such as setting an actuator output to either ON or OFF The parameters associated with this service are detailed in Table 3.

Table 3 - Parameters defined for write service

Logical Address—EOID Mandatory (=) Request received Mandatory (=) Response received

Attribute ID Mandatory (=) Request received Mandatory (=) Response received

Attribute Value Mandatory (=) Request received

The parameters serve specific functions: the Logical Address is essential for identifying the target device for attribute data in both the Request and Response The EOID (Embedded Object ID) indicates the specific Embedded Object to be written, while the Attribute ID denotes the particular attribute being modified, as defined in the Object Model.

The Attribute Value represents the value assigned to a specific attribute If the write operation is successful, the Result (+) parameter returns the attribute ID Conversely, if the write operation fails, the Result (–) parameter is returned, which includes the attribute ID along with an error code that explains the reason for the failure.

Event service

This service is designed to report specific events related to an Embedded Object, such as a Logical Device indicating a self-test failure Detailed parameters for this service are outlined in Table 4.

Table 4 - Parameters defined for event service

Event ID Mandatory (=) Request received Mandatory (=) Response received

Event Parameters Conditional (=) Request received

The parameters serve specific functions: the Logical Address identifies the device where the event took place, while the EOID (Embedded Object ID) indicates which Embedded Object is transmitting The Event ID denotes the specific event that occurred, with its value outlined in the Object Model of the sending Embedded Object Additionally, the Event Parameters vary based on the event type and are defined accordingly.

The Object Model specifications include the Result (+) parameter, which is returned with the event ID upon a successful event Conversely, the Result (–) parameter is provided when an event fails, returning the event ID along with an error code that explains the reason for the failure.

Action service

The action service is utilized to perform tasks associated with an Embedded Object, such as initiating a self-test Detailed parameters for this service are outlined in Table 5.

Table 5 - Parameters defined for action service

Action ID Mandatory (=) Request received Mandatory (=) Response received

Action Parameters Conditional (=) Request received

Conditional Mandatory Conditional (=) Response received

The parameters serve specific functions: the Logical Address is essential for identifying the target device for action requests in both Request and Response messages The EOID (Embedded Object ID) indicates which Embedded Object will execute the action, while the Action ID defines the specific action to be performed, as detailed in the Object.

Action parameters vary based on the type of action and are defined within the Object Model When an action is successfully executed, the Result (+) parameter is returned, which includes the action ID and its associated parameters Conversely, if the action request fails, the Result (–) parameter is provided, containing the action ID and an error code that explains the reason for the failure.

Change Of State ON (COS ON) service

A Logical Device will utilize this event service to indicate when its state changes to ON, specifically for devices that feature only one binary Embedded Object, such as a single binary input The parameters for this service are detailed in Table 6.

Table 6 - Parameters defined for Change Of State ON service

Logical Address Mandatory (=) Request received Mandatory (=) Response received

The parameters serve specific functions: the Logical Address identifies the device where the Change Of State to ON occurred, while a successful report returns a Change of State ON Acknowledge (COS ON ACK) Additionally, the Result (–) parameter is not defined for this service.

Change Of State OFF (COS OFF) service

A Logical Device will utilize this event service to indicate when its state changes to OFF This service is specifically designed for devices that feature only one binary Embedded Object, such as a single binary input For detailed parameters related to this service, please refer to Table 7.

Table 7 - Parameters defined for Change Of State OFF service

The parameters serve specific functions: the Logical Address identifies the device where the Change of State (COS) to OFF occurred, while a successful report returns a Change of State OFF Acknowledge (COS OFF ACK) Additionally, the Result (–) parameter is not applicable for this service.

Write State ON (WRITE ON) service

This service is designed to write an ON state to a Logical Device, specifically for devices that include only one binary Embedded Object, such as a single binary output The parameters for this service are detailed in Table 8.

Table 8 - Parameters defined for Write State ON service

The parameters serve specific functions: the Logical Address designates the device that will be activated, while a successful write operation is confirmed by a Write ON Acknowledge (WRITE ON ACK) response It is important to note that the Result (–) parameter is not applicable for this service.

Write State OFF (WRITE OFF) service

This service is designed to write an OFF state to a Logical Device that contains a single binary Embedded Object, such as a binary output The parameters for this service are detailed in Table 9.

Table 9 - Parameters defined for Write State OFF service

The parameters serve specific functions: the Logical Address designates the device intended to enter the OFF state, while a successful write operation is confirmed by a Write OFF Acknowledge (WRITE OFF ACK) Additionally, the Result (–) parameter is not applicable for this service.

SDS Application Layer Protocol

Application Protocol Data Unit (APDU)

NOTE A number of defined APDU types supports all SDS services.

APDU components are defined in a fixed format as outlined in section 5.3.2, while other components include variable parameters that can be standard SDS data types or derived from them These parameters must be encoded following the guidelines specified in section 5.3.4.

5.3.1.2 Address coding within the APDU

The address field must follow a fixed format, with each Physical Component on the Network comprising one or more Logical Devices, each assigned a unique SDS address Additionally, each Logical Device includes one or more embedded I/O Devices or other Object Models, each identified by a distinct 5-bit Embedded Object Identifier.

5.3.1.3 SDS addressing within the CAN protocol

The SDS Application Layer Protocol (ALP) defines that the CAN Identifier bit 10 (ID10) shall be the

Direction/Priority bit and CAN Identifier bits 3 through 9 (ID3 —ID9 ) shall be the Logical Address bits This allows Logical Addresses 0 through 125 The CAN frame format is shown in Figure 8.

ID10 ID9 ID8 ID7 ID6 ID5 ID4 ID3 CAN

B ID2 ID1 ID0 RTR DLC

In the CAN specification, logical addresses 126 and 127 are restricted and cannot be utilized Additionally, when CAN controllers are configured to filter messages, they minimize the volume of incoming messages that require processing In the context of SDS, the CAN controller filter is specifically set to its designated SDS address, known as the Logical Device address.

APDU Forms

The Application Layer Protocol Data Unit (APDU) can be categorized into two types: short form and long form Long form APDUs can either be non-fragmented or fragmented, with fragmented APDUs utilized for data that surpasses the maximum size of non-fragmented APDUs.

In this section, each field and subfield of the APDU is defined upon its first mention, accompanied by a diagram illustrating the main APDU fields The primary field is highlighted with a bold frame, while any previously defined primary fields will feature a double frame Additionally, any unused fields will be assigned a value of 0, as indicated in Diagram 1.

The short form APDU is 44 bits long, with 16 bits allocated for SDS and the remaining bits designated for CAN The first 8 bits of the CAN Identifier encode the Direction/Priority (Dir/Pri) bit and Logical Address, while the next 3 bits indicate the Service Type The Remote Transmission Request (RTR) bit is set to 0, and the Data Length Code (DLC) represents the number of actual CAN data bytes For short form APDUs, the DLC is always 0, as no CAN data bytes are utilized.

Service Type {0 7} RTR=0 Data Length Code = 0 Header Header

Figure 9 - Short form APDU structure

5.3.2.2.2 Direction/Priority (Dir/Pri) field

In short form APDUs, the Dir/Pri bit indicates the direction of the Logical Address field A Dir/Pri bit value of 1 signifies a source address, while a value of 0 indicates a destination address Additionally, messages addressed to a destination are prioritized over those addressed to a source.

In the context of short form APDU, the CAN Identifier bits 3 to 9 represent the Logical Address bits, allowing for 7 address bits and enabling Logical Addresses ranging from 0 to 125 The logical address field, in conjunction with the priority level defined by the Dir/Pri bit, establishes the priority for accessing the SDS network, where a lower address number corresponds to a higher priority.

The second byte of the short form APDU specifies the service type that identifies the message type, with devices containing a single binary Embedded Object utilizing short form service types The type values are encoded in data bits 5 to 7 of the second byte (CAN ID0 – ID2), as detailed in Table 10.

Table 10 - Short form service type values

Change of State OFF ACK (2) 0 1 0

Change of State ON ACK (3) 0 1 1

5.3.2.2.5 Data Length Code (DLC) field

The DLC field shall always represent the CAN Data field length in bytes For short form APDUs, the DLC shall always be 0.

5.3.2.3 Generic Long form APDU specification

The long form APDU, as illustrated in Figure 10, is designed for messages that necessitate more detailed information than the short form APDU can offer It is characterized by a non-zero Data Length Code, distinguishing it from the short form This long form is essential for accessing devices with multiple Embedded Object Identifiers The APDU comprises data fields that contain addressing and service information, including the Dir/Pri bit, Logical Address, Embedded Object Identifier, and service parameters.

The service type field specifies the APDU type, while the RTR bit must be set to 0 The Data Length Code indicates the number of CAN data bytes, and the service specifiers field contains the Request/Response and Fragmentation Indicator subfields Additionally, the EOID field holds the Embedded Object Identifier, and the service parameters field includes the service identifier and/or other parameters, coded in the second CAN data byte.

NOTE Some APDUs may use more than a single byte for their service parameters The format of the service parameters is dependent on the service type.

Service Type {0 7} RTR=0 Data Length Code {2 8} Header SDS

Figure 10 - Long form APDU format

5.3.2.3.2 Direction/Priority (Dir/Pri) field (generic)

In a long form APDU for service types such as read, write, action, and event, the Dir/Pri bit indicates the direction related to the Logical Address field When the Dir/Pri bit is set to 1, the address field represents a source address; conversely, when it is set to 0, the address field signifies a destination address.

In the long form APDU, the bits 3 through 9 of the CAN Identifier (ID3 – ID9) represent the Logical Address bits, allowing for 7 address bits and enabling Logical Addresses ranging from 0 to 125 The logical address field, in conjunction with the priority level defined by the Dir/Pri bit, establishes the priority for accessing the SDS Network, where a lower address number corresponds to a higher priority.

The long form service types include: read, write, action and event (see Table 11).

Table 11 - Long form service types

5.3.2.3.5 Data Length Code (DLC) field (generic)

The Data Length Code field in the long form APDU, represented by data bits 0 through 3 of the second byte, specifies the number of CAN data bytes A long form APDU must contain a minimum of 2 CAN data bytes, which encompass service specifiers, EOID, service parameters, and any optional data The valid range for the Data Length Code in a long form APDU is between 2 and 8, inclusive (refer to Table 12).

Table 12 - Data Length Codes for long form APDUs

The service specifiers field shall consist of the Request/Response and Fragmentation Indicator subfields.

The Request/Response subfield, bits 6 and 7 of the service specifiers field, shall specify whether the message is a request, successful response or an error response (see Table 13).

Table 13 - Request/Response subfield for long form APDUs

A request message shall request a specific service from a Service Provider.

A successful response message shall notify the initiating device that the requested service has been successfully completed.

An error response message will inform the initiating device of any errors encountered while processing the requested service, with a dedicated data field containing the specific error code.

Y Service Type {0 7} RTR=0 Data Length Code{2 8} Header SDS

T R/R = Error FI = 0 EOID {0 31} CAN Header

Figure 11 - Error response APDU format

The placement of the error code in the APDU format can differ based on the service type, as it is influenced by the varying lengths of the service parameters field.

See 5.3.3, error codes, for SDS error code specifications The error code data type shall be Unsigned 8.

The Fragmentation Indicator (FI), located in bit 5 of the service specifiers field, determines if the APDU format is fragmented or non-fragmented A value of 0 indicates a non-fragmented APDU, while a value of 1 signifies a fragmented APDU, as detailed in Table 14.

Table 14 - Fragmentation Indicator (FI) subfield

5.3.2.3.7 Embedded Object Identifier (EOID) field (generic)

Bits 0 to 4 inclusive of the first CAN Data Byte shall form the Embedded Object Identifier This identifier shall be used as a selector to distinguish the specific Embedded Object addressed by the particular APDU

Table 15 - Embedded Object Identifier field

The Service Parameters field shall be used to determine how an APDU will be processed Its definition varies according to the service type.

Error Codes

When the service specifiers indicate the message is an error response, the data portion of the APDU shall contain an error code as shown in Table 16.

Error Code Error Code Name Definition

0 Service Not Available Service type was {0 3} with DLC (CAN Data Length Code)

1 Illegal Service Parameters Requested service parameters does not exist in this object.

2 Read Only Variable A write action was requested of a read-only variable.

3 Illegal Data The data for a specific variable is incorrect.

4 EEPROM Read Error Non-volatile memory error.

5 Time Out Resource was not available.

6 Unable To Respond Request could not be honoured at this time, unable to respond.

Unavailable The embedded object addressed is not available.

8 Illegal Object EOID value out of range for Logical Device.

9 Illegal DLC DLC value does not match data byte count.

254 ALP Service Timeout No response to a request message within the specified time limit.

255 Other Network Other Network level error.

Data types

SDS data types are defined by Embedded Object specifications for each service parameter, with variable data in the APDU containing parameters that are either SDS base data types or constructed from them Values are encoded with the most significant byte (MSB) first, and within each byte, the most significant bit is prioritized, ensuring the entire value is least significant byte (LSB) justified Detailed coding for each data type is outlined in the subsequent sections.

Boolean value shall be coded in a single byte, with the value 0x00 for FALSE and 0x01 for TRUE.

The Unsigned 8 Integer data type is represented as binary numbers ranging from 0 to 255, utilizing one byte (8 bits) for coding For instance, the decimal value 70 is encoded as 0x46.

Data elements shall be coded in two bytes (16 bits) in the range of 0 to 65 535 Example: The value 258 is coded as 0x0102 (see Figure 13).

Data elements shall be coded in four bytes (32 bits) with a maximum value of 4 294 967 295 For example, a value of 8 262 is coded as 0x00002046 (see Figure 14).

Signed integers are represented in binary using 2’s complement notation, where an 8-bit signed integer occupies 1 byte In this format, the most significant bit (data bit 7) indicates the sign, with a value of 1 denoting negative numbers For example, a Signed 8 Integer value of -127 in decimal is illustrated in Figure 15, showcasing the sign bit as negative.

A Signed 16 Integer value requires 2 bytes, and for negative values, data bit 7 of the most significant byte (MSB) shall be 1 Figure 16 shows the bit values for a negative 0x46

A signed 32-bit integer occupies 4 bytes, with the most significant byte's data bit 7 set to 1 for negative values For instance, Figure 17 illustrates the bit representation of the positive integer 2,105,414, encoded as 0x00202046.

Single precision real numbers shall be coded in four bytes No double precision real numbers shall be supported.

Figure 18 - Real numbers 5.3.4.10 Character strings

Each character shall be coded in one byte using its ASCII value.

The date code for the date of manufacture shall be a four byte ASCII string starting with the year tens digit, yy/ww, week of product manufacture (see Figure 19).

The date code for other dates shall be six bytes, beginning with the year tens digit and is in the form of yy/mm/dd (see Figure 20).

Figure 19 - Format for ‘manufacturing date’ coding

SDS APDUs embedded in CAN frames

SDS APDUs shall be embedded in CAN frames as shown in the examples given in Figure 21, Figure 22 and Figure 23.

SDS Header SDS Footer SDS Fields

CAN Header CAN Footer CAN Fields

RB0 DLC CRC ACK EOF FIELD NAME

NOTE 1 Italicized fields may not be changed

NOTE 2 The following abbreviations are defined in the CAN specification ISO 11898.

Figure 21 - SDS short form APDU

SDS Header SDS Data Field SDS Footer SDS Fields

CAN Header CAN Data Field CAN Footer CAN Fields

Parameters Data Data Data Data Data Data CRC ACK EOF FIELD NAME

Figure 22 - SDS long form APDU

SDS Header SDS Data Field SDS Footer SDS Fields

CAN Header CAN Data Field CAN Footer CAN Fields

Bytes Data Data Data Data CRC ACK EOF FIELD NAME

DLC ạạạạ 0 RRE FI EOID

NOTE Italicized fields may not be changed.

Figure 23 - SDS long form fragmented APDU

Example Short Form APDUs

Example Short Form APDUs are shown in Figure 24 and Figure 25.

RB1,RB0 DLC CRC ACK EOF FIELD NAME

Figure 24 - COS OFF APDU from Logical Address 25

RB1,RB0 DLC CRC ACK EOF FIELD NAME

OFF ACK not used - No

Figure 25 - COS OFF ACK APDU to Logical Address 25

Example Long Form APDUs

Example Long Form APDUs are shown in Figure 26 and Figure 27.

CAN Header CAN Data Field CAN Footer

Service Specifiers RRE,FI EOID

Service ParametersCRC ACK EOF FIELD NAME

16 Read not used - 2 Bytes Request Object 0 Attribute

Figure 26 - Read Request to Logical Address 16, Embedded Object 0, Variable 8

CAN Header CAN Data Field CAN Footer

Service Parameters Data CRC ACK EOF FIELD NAME

Figure 27 - Read Response from Logical Address 16, Embedded Object 0, Variable 8

Instructions for installation, operation and maintenance

Instructions for installation, operation and maintenance shall be in accordance with 6.1 of EN 50325-1.

Marking shall be in accordance with 6.2 of EN 50325-1.

7 Normal service, transport and mounting conditions

Normal service conditions

General

Components of an SDS Network shall be capable of operating under the following conditions.

If the operational conditions vary from the specified standards, the user must indicate these deviations and seek guidance from the manufacturer regarding the appropriateness of use under those conditions.

Ambient air temperature

SDS components are designed to function effectively within an ambient temperature range of -25 °C to +70 °C, unless specified otherwise for particular actuators or sensors It is essential that the operating characteristics remain stable throughout this permissible temperature range.

Altitude

SDS components shall be capable of operating at altitude in accordance with 7.1.3 of EN 50325-1

Humidity

SDS components shall be capable of operating in humid conditions in accordance with 7.1.4 of EN 50325-1.

Pollution degree

SDS components shall be capable of operating in polluted conditions in accordance with 7.1.5 of

Sealed connectors

Sealed connectors, when provided with SDS components, shall be in accordance with 7.1.6 of EN 50325-1.

Conditions during transport and storage

Conditions during transport and storage shall be in accordance with 7.2 of EN 50325-1.

Mounting

SDS components shall be mounted in accordance with 7.3 of EN 50325-1

NOTE Constructional requirements are verified by inspection and the performance requirements are verified by the tests of clause 9.

SDS Physical Layer Interface (PLI)

SDS power PLI

An SDS PLI operates with a voltage range of 11 to 25 volts DC and can utilize SDS power to power its microcontroller and other non-SDS related circuitry Additionally, an SDS device has the capability to supply SDS power to other devices not directly connected to the SDS power lines, with any power derived from these lines classified as SDS power.

There is no specified limit for device SDS current consumption, however the maximum value shall be specified by the manufacturer.

In addition to SDS power an SDS node may also have an auxiliary power port Auxiliary power is not limited to any specific type (e.g., DC, AC, or 3 ặ AC).

An SDS device must ensure galvanic isolation between its power supply and any auxiliary power sources, as well as between each power source and the device casing, in accordance with applicable product standards.

The shield line must remain unconnected to both the SDS power and the device case Additionally, the device case should not be linked to either the SDS power or the auxiliary power.

Transceivers

An embedded transceiver connects each Physical Component to the SDS Network, enabling these devices to transmit and receive data from one another through the Network.

NOTE 1 The Discrete transceiver is comprised of discrete electronic components This option provides extremely low power consumption with quiescent supply current typically 0 mA.

NOTE 2 The Integrated transceiver is a single electronic package, typically an integrated circuit component The benefit of this option is reduced size.

NOTE 3 The Optocoupled transceiver has the additional feature of galvanic isolation of the input/output terminals providing maximum protection from power system faults and ground loops.

Transceiver specifications

The discrete transmitter and receiver specifications shall be in accordance with Table 17 and Table 18.

Electrical Characteristics Specifications Differential Output Level, OFF -0.5 to 0.05 V

Differential Output Level, ON 1.5 to 4.0 V

Differential Input Impedance (Rdiff), OFF (minimum)

Electrical Characteristics Specifications Differential Input Levels, OFF -0.5 to 0.6 V

Differential Input Levels, ON 0.9 to 5.0 V

The integrated transmitter and receiver specifications shall be in accordance with Table 19 and Table 20.

Electrical Characteristics Specifications Differential Output Levels, OFF -0.5 V to 50 mV

Differential Output Levels, ON 1.5 V to 3.0 V

Differential Input Impedance (Rdiff) (min) 20 kW

I recessive CAN state (maximum) 18 mA

Electrical Characteristics Specifications Differential Input Levels, OFF -1.0 V to 0.4 V

Differential Input Levels, ON 1.0 V to 5.0 V

The optocoupled transmitter and receiver specifications shall be in accordance with Table 21 and Table 22.

Electrical Characteristics Specifications Differential Output Levels, OFF -0.5 V to 50 mV

Differential Output Levels, ON 1.5 V to 3.0 V

Differential Input Impedance (R diff ) (min) 20 kW

I recessive CAN state (maximum) 18 mA

Electrical Characteristics Specifications Differential Input Levels, OFF -1.0 V to 0.4 V

Differential Input Levels, ON 1.0 V to 5.0 V

Indicating means

SDS physical devices may feature colored indicators that convey specific meanings: a green indicator signifies that communication is in progress, while a red indicator indicates a fault in the system or communication.

SDS Network

Topology

The physical arrangement and spacing of the trunk, branches, and nodes must adhere to specific requirements A standard SDS topology features a single trunk with short branches, necessitating a minimum node separation of 300 millimeters for SDS standard cables and 100 millimeters for conventional wiring Additionally, when using standard cables, no more than four tees may be directly connected without an intervening section of trunk cable, while conventional wiring prohibits multiple connections to the same terminal.

The voltage drop on the power pair of an SDS cable significantly influences the network length and physical layout of an SDS system Key factors that contribute to voltage drop include the resistance of the conductors and connections, as well as the current requirements of each node.

The difference in the power supply voltage between any two SDS Physical Components shall not exceed

Table 23 shows the general requirements for SDS bus cable.

Table 23 - SDS cable general requirements

Cable Construction Two shielded, twisted pairs, with a common earth wire, all within a single jacket

The operating temperature range for the connectors is from -30°C to +70°C They feature a minimum plating of 0.76 mm of gold over 0.76 mm of nickel Additionally, mated connectors are required to endure power and temperature cycling without experiencing electrical discontinuities exceeding 1 ms, while being cycled between -30°C and +70°C at a ramp rate of 1°C to 3°C per minute.

30 minute dwell at 70°C, and with power (6.0 mA @ 5 V) continuously cycled on/off (50K times total) concurrent with (35) complete (up/down) temperature cycles.

Table 24 gives the specifications for SDS standard cables which have either Mini or Micro interface connectors.

Table 24 - SDS standard cable specifications

Category MINI Specification MICRO Specification

Pin/Socket Resistance (typical) 1 mW 4 mW

Table 25 gives maximum system trunk lengths, maximum branch lengths and maximum nodes for various data rates, without taking in account the voltage drop.

Table 25 - Maximum trunk and branch lengths and maximum nodes for various data rates

Table 26 gives the wire terminations and colour code for SDS standard cables.

Table 26 - SDS standard cable wire termination and colour code

SDS power distribution

An SDS power supply shall be connected to the trunk in only one place and the power return line shall only be connected to earth at the power supply.

Auxiliary power ground connection

Figure 28 illustrates the grounding connections for a network that incorporates both SDS power and auxiliary power, highlighting the necessity of a single connection to the power supply V- and a unified ground connection for the power supply return interconnection.

Electromagnetic Compatibility (EMC)

General requirements for electromagnetic compatibility tests

The operating characteristics of SDS shall be maintained at the specified levels of electromagnetic interference (EMI).

The SDS device undergoing testing must possess all critical design specifications representative of its type and should be in pristine, new condition It is important to note that maintenance or replacement of any parts during or after the testing cycle is strictly prohibited.

Compliance with this requirement can be demonstrated using a network comprising one controller, one device and one power supply.

General test conditions for electromagnetic compatibility tests

Unless otherwise stated the tests shall be carried out at an ambient temperature of +23 ± 5° C.

The tests shall be performed under the following conditions:

The SDS device, installed in open air, must be linked to the SDS line and powered with its designated operational voltage Connections for terminals and connectors should be made to the appropriate sensors or actuators following the manufacturer's guidelines Testing is required at each baud rate using the branch length outlined in Table 27.

Immunity requirements

The test specimen shall continue to operate as intended during and after the test.

No change of operating state or stored data is allowed within the equipment under test (EUT). a) Sensors, I/O Devices, I/O Devices w/Ext Power, and Controller:

- Any I/O interface line shall not have a false pulse > 1 às.

- All input stimulus shall match the resulting output state in node/controller pairs.

- Stimulus may range from 10 to 100 Hz. b) Allowable degradation in performance:

- audible signals and/or visible indicators not associated with control I/O

- excessive data bus traffic (transmission retries, error frames, etc ) c) Not allowable degradation in performance:

- change in analogue value > 10 X nominal tolerance

- false I/O data representation in controller

- change of stored data in a device

- system stops operating and requires to be reset

- device self test failure indication

During the tests a temporary loss of the data communication may occur, thereafter the SDS device shall continue to operate as intended.

No change of actual operating state or stored data shall be allowed.

The SDS device, when tested in accordance with EN 61000-4-2, shall

The licensed copy, identified as :FULLNAME and dated :DATE, is an uncontrolled document (c) BSI It specifies that all conductive surfaces must withstand a voltage of 4 kV using the contact discharge method, while all non-conductive surfaces must endure a voltage of 8 kV through the air gap discharge method Performance criteria B will be applicable.

8.3.3.3 Radiated radio-frequency electromagnetic field immunity

The SDS device shall withstand severity level 3 (10 V/m) when tested in accordance with EN 61000-4-3 at a frequency band of 80 MHz to 1000 MHz, amplitude modulated.

The SDS device shall withstand severity level 3 (10 V/m) when tested in accordance with EN 61000-4-3 at a frequency band of 900 MHz + 5 MHz, pulse modulated.

Performance criteria A shall be applied.

8.3.3.4 Conducted radio-frequency disturbance immunity

The SDS device shall withstand a voltage of 10 Vrms when tested in accordance with EN 61000-4-6 at a frequency band of 150 kHz to 80 MHz, amplitude modulated.

Performance criteria A shall be applied.

The SDS device must endure 5/50 Tr/Th ns transients at a 5 kHz repetition frequency, as per EN 61000-4-4 standards Specifically, signal line and data bus ports not related to process control should withstand 1 kV (peak), while ports for process, measurement, and control lines, as well as long bus and control lines, must handle 2 kV (peak) Additionally, both DC and AC input and output power ports are required to withstand 2 kV (peak).

Performance criteria B shall be applied.

Surge immunity testing is not required for target and I/O devices, as their operating environment is deemed sufficiently protected from surge voltages resulting from lightning strikes.

The SDS device must endure a 1.2/50 (8/20) Tr/Th ms surge as per EN 61000-4-5 testing standards Specifically, process, measurement, and control line ports should withstand 2 kV for common mode and 1 kV for differential mode Additionally, DC input and output power ports are required to handle 0.5 kV for both common and differential modes Lastly, AC input and output ports must be capable of withstanding 4.0 kV for common mode and 2.0 kV for differential mode.

Performance criteria B shall be applied.

The system shall be capable of operating with SDS power supply interruptions of less than or equal to 1 millisecond.

Emission requirements

SDS devices shall meet the requirements of EN 50081-2 when tested in accordance with EN 55011.

SDS devices shall not produce radiated emissions that exceed the limits given in Table 28 when tested in accordance with EN 55011 for Class A Group 1 equipment.

Table 28 - Radiated emissions test limits

(MHz) Measured on a test site at 30 m distance (dBmmmm V/m)

SDS devices are designed solely for industrial use; however, if they are to be utilized in a domestic setting, it is essential to include a warning in the user instructions.

This is a Class A product In a domestic environment this product may cause radio interference, in which case the user may be required to take adequate measures.

9 SDS Communication channel type tests

General

The Smart Distributed System communication channel of a product shall be verified by the following tests.

This clause employs standard product addressing conventions, primarily utilizing User Addresses in test descriptions It is important to note that all address references, as they appear on the Network or within actual message fields, are classified as Logical Addresses.

Product Model

The tests outlined in this clause are based on the manufacturer’s Product Model and the Object Model(s) utilized by the Equipment Under Test (EUT) These tests aim to ensure that the EUT complies with the manufacturer’s Product Model, the Object Model, all relevant Smart Distributed System specifications, the means of connection, and the transceiver type.

Object Model test

General

All attributes, actions and events defined in the Object Model documentation shall be verified with the SDS power supply set to DC 11V, unless otherwise specified.

The device conformance test set-up includes a single controller (Device Conformance Tester), a single device (EUT), a power supply and a network monitor The set-up is shown in Figure 29.

Figure 29 - Device conformance test set-up

Attributes

9.3.2.1 Test procedure a) Issue a read request message for each attribute identified in the Object Model of the EUT. b) Issue a write request message for each writeable attribute identified in the Object Model of the EUT. c) Issue an action request message READ PRIMITIVE TAG for each attribute identified in the Object Model of the EUT. d) If the EUT has alternative modes which should not effect the product’s response, test the EUT in each mode to verify the specified responses.

Bus Power + Bus Power - Bus Com + Bus Com -

9.3.2.2 Test results a) Record whether the correct response message was produced for each read request. b) Record whether the correct response message was produced for each write request. c) Record whether the correct response message was produced for each action request.

Actions

9.3.3.1 Test procedure a) Issue an action request message for each action identified in the Object Model of the EUT. b) If the EUT has alternative modes which should not effect the product’s response, test the EUT in each mode to verify the specified responses. c) If the EUT has alternative modes which should effect the product’s response, test the EUT in each mode to verify the specified responses. d) If alternative request message formats are specified for an action, test each format.

Record whether the correct response message was produced for each action request.

Events

9.3.4.1 Test procedure a) Apply stimulus to the EUT for each event identified in the Object Model of the EUT. b) If alternative modes to release event messages are specified for the EUT, test each mode.

Record whether the correct event message was produced for each specified condition.

Short form services COS ON and COS OFF

NOTE This test only applies to Object Models which specify a single binary input and/or a single binary output.

Stimulate the EUT as specified to produce short form services COS ON and COS OFF.

If the COS ON and COS OFF services are not used for the EUT, it is essential to ensure that the EUT does not issue any related messages, regardless of the product stimulation.

Record whether the correct COS ON and COS OFF messages are produced by the EUT e.g the SDS controller responds with the correct COS ON ACK or COS OFF ACK.

Short form services WRITE ON and WRITE OFF

NOTE This test only applies to Object Models which specify a single binary input and/or a single binary output.

9.3.6.2 Test results a) Record whether the correct WRITE ON ACK and WRITE OFF ACK messages were produced by the EUT. b) Record whether the EUT correctly performed the specified output state change.

Physical Layer Test

Transceiver functional test

9.4.1.1 Test procedure a) Connect the EUT to the controller with the SDS power supply set to DC 18V. b) Initiate an Autobaud sequence by the controller.

Record whether the EUT performed correctly during the Autobaud sequence.

Transceiver Input Resistance

NOTE This test only applies to EUTs using a discrete transceiver.

9.4.2.1 Test procedure a) Measure and record the Transceiver Input Resistance R DIFF OFF

Record and verify that RDIFF OFF is greater than or equal to the minimum specified value (see Figure 30) when the transceiver is in the non-dominant state (i.e not transmitting).

Transceiver input levels

9.4.3.1 Test procedure a) Set the SDS power supply to DC 11V. b) Set the resistor switches to the positions R1-IN and R2-OUT as shown in Figure 30. c) Perform an Autobaud sequence by the controller. d) Issue a read request message to any single attribute identified in the Object Model of the EUT. e) Measure and record the differential input voltage level VDIFF at the EUT, while the read request message is present. f) Set the resistor switches to the positions R1-OUT and R2-IN. g) Issue a read request message to any single attribute identified in the Object Model of the EUT. h) Measure and record the differential input voltage level VDIFF at the EUT, while the read request message is present. i) Set the SDS power supply to DC 25V. j) Repeat test steps b) to I).

Record and verify that the measured values are within the limits as specified in 8.1.3.1.

Transceiver output levels

Figure 31 - Output level test circuit

9.4.4.1 Test procedure a) Set the SDS power supply to DC 25V. b) Stimulate the EUT to send SDS messages onto the SDS Network c) Record the recessive and dominant output signals of the EUT with an oscilloscope.

Record and verify that the measured values are within the limits as specified in 8.1.3.1

SDS power

9.4.5.1 SDS power - voltage range test

To conduct the test procedure, first set the SDS power supply to DC 25V and then switch it OFF before turning it back ON to initiate an Autobaud sequence from the controller Next, adjust the SDS power supply to DC 11V, switch it OFF again, and then turn it ON to trigger another Autobaud sequence from the SDS controller.

9.4.5.1.2 Test results a) Record and verify that the EUT performs both Autobaud sequences successfully. b) Record and verify that the correct device address of the EUT is reported by the controller.

9.4.5.2 SDS Power - maximum current test

To conduct the test procedure, first connect a current meter in series between the power supply V+ and the EUT V+, ensuring the meter input is linked to the power supply Next, set the SDS power supply to a DC voltage of 11V and gradually increase it to a maximum of 25V Finally, record the maximum current supplied by the power supply during this process.

Record and verify that the maximum power supply current is less or equal to the value, specified in the product data sheet.

9.4.5.3 SDS power - current loss test

C onductive Case or any external conductive parts

NOTE If the case is not conductive, make the connection at the connector shell (if standard connector) If the product has no conductive external parts, omit the case connection.

Figure 32 - Current loss test set-up

9.4.5.3.1 Test procedure a) Set the SDS power supply to DC 24V. b) Measure the current values I1 and I2 as shown in Figure 32. c) Calculate the difference between I1 and I2 (I1 - I2).

Record and verify that the difference between I1 and I2 (I1 - I2) is < 0,1mA.

Application Layer Test

ALP Services

All ALP tests in this subclause require adherence to specific general test instructions It is essential to verify the data format of all EUT messages during the testing process outlined in this subclause.

The data format shall comply with the following requirements Verify that the data, for each message field, is within the range specified in Table 29.

Message Message field Valid data values

All Messages Device Logical Address 0 - 125

Short Form Messages Service Type 0 - 7

Verify proper message structure (e.g short form response for short form request).

9.5.1.4 Product reaction to double messages

Verify a single response for each request (at least two requests - minimize delay between requests).

Verify single response only, from product when presented a single request.

Verify proper decoding of message fields (e.g attribute ID).

To conduct the test procedure, issue an action request NOOP message at least once every second Then, measure the time interval from the completion of the action request NOOP message to the start of the action response NOOP message using the SDS monitor.

Record and verify that the measured time between the request and the response message is less or equal

NOTE This test only applies to single binary Object Models.

Stimulate the EUT as specified to release a COS ON message.

Verify that a COS ON message is issued by the EUT.

Stimulate the EUT as specified to release a COS OFF message.

Verify that a COS OFF message is issued by the EUT.

Issue a WRITE ON message to the EUT.

Verify that a WRITE ON ACK message is issued by the EUT.

Issue a WRITE ON message to the EUT.

Verify that a WRITE ON ACK message is issued by the EUT.

Issue a read request message to a readable attribute of the EUT.

Verify that a read response message is issued by the EUT, with the appropriate attribute ID and data.

Issue a write request message to a writeable attribute of the EUT.

9.5.1.13.2 Test results a) Verify that a write response message is issued by the EUT.

Issue an action request message to the EUT.

Verify that an action response message is issued by the EUT.

Stimulate the EUT, as described in the product documentation, so that it will release an event.

Verify that an event request message is issued by the EUT.

Issue a fragmented write request message to the EUT.

Verify that a single write response message is issued by the EUT.

Issue a fragmented action request message to the EUT.

Verify that a single action response message is issued by the EUT.

Stimulate the EUT, as described in the product documentation, so it will release a fragmented event request message.

9.5.1.18.2 Test results a) Verify that a multiple fragmented event request message is issued by the EUT. b) Verify that the single fragmented event messages are issued sequentially, starting with fragment number

0 (zero). c) Verify that the composite data from the group of fragmented event request messages is the expected product data.

Logical Device functions

Issue read request messages to each Logical Address 0 to 125 inclusive.

In the testing process, it is essential to confirm that the Equipment Under Test (EUT) generates a read response message exclusively when addressed by its valid Logical Address Additionally, it must be verified that no response messages are produced by the EUT when addressed by any addresses other than its valid Logical Address.

Issue read request messages to each possible attribute of the EUT, 0 to 255 inclusive.

To ensure proper functionality, it is essential to verify that the Equipment Under Test (EUT) issues a read response message for every read request Additionally, a positive response must be confirmed when the addressed attribute is present in the EUT's Object Model Conversely, a negative response, including an error code, should be issued when the addressed attribute is absent from the Object Model.

Issue action request messages to each possible action of the EUT, 0 to 255 inclusive.

To ensure proper functionality, it is essential to verify that the Equipment Under Test (EUT) generates an action response message for every action request Additionally, a positive response must be confirmed when the requested action is included in the EUT's Object Model Conversely, if the action is not part of the Object Model, the EUT should issue a negative response that includes an error code.

Stimulate the EUT, as described in the product documentation, so that it will release each specified event message.

Network functions

To conduct the test procedure, first configure the controller to a baud rate of 125 kbit/s and set the EUT address to 1 Next, issue an Autobaud sequence using the SDS controller, then adjust the EUT address to a value between 10 and 110 and repeat the Autobaud sequence Subsequently, set the EUT address to 126 and issue another Autobaud sequence After completing these steps, increase the SDS controller's baud rate to 250 kbit/s and repeat the previous steps (b to g) Continue this process by configuring the SDS controller to baud rates of 500 kbit/s and 1 Mbit/s, ensuring to repeat steps b) to g) for each baud rate adjustment.

The test results indicate that the Equipment Under Test (EUT) is successfully recognized by the SDS controller following each Autobaud sequence Additionally, it is confirmed that all Autobaud tests are conducted without any detection of CAN Error Status at the controller.

NOTE This subclause only applies when the heartbeat option is specified in the EUT product documentation.

9.5.3.2.1 Test procedure a) Enable the EUT to perform heartbeat behaviour. b) Stimulate the EUT, as specified in the product documentation, so that a heartbeat condition occurs.

9.5.3.2.2 Test results a) Verify that the EUT issues heartbeat messages which are long form Action NOOP request messages. b) Verify that the heartbeat messages repeat as specified in product documentation.

System test

Electromagnetic Compatibility Test

Tiêu đề	Industrial Communications Subsystem Based On Iso 11898 (Can) For Controller-Device Interfaces — Part 3: Smart Distributed System (Sds)
Trường học	British Standards Institution
Chuyên ngành	Industrial Communications
Thể loại	British standard
Năm xuất bản	2001
Thành phố	London

Định dạng
Số trang	64
Dung lượng	704 KB