AS-i/Sercos III Safety Gateway BWU 2984 by Bihl+Wiedemann - Device Integration
This topic contains the following information:
Term definition: the AS-i/Sercos III Safety Gateway BWU 2984 by Bihl+Wiedemann is referred to as AS-i Gateway for short in this documentation.
Purpose of the AS-i Gateway integration
The AS-i Gateway connected to the Sercos bus enables the communication of the Safety Logic Controller with AS-i sensor and actuator system components. The safety-related communication between the SLC and the AS-i Gateway complies to the openSafety over Sercos III specification.
The AS-i Gateway enables you to:
integrate AS-i sensors/command devices (such as light curtains, emergency stop buttons, etc.) and AS-i actuators (e.g., contactors) into the safety-related PacDrive 3 system architecture,
monitor and evaluate AS-i sensors/command devices in the safety-related SLC application,
react on safety-related requests coming from AS-i sensors/command devices by switching safety-related Sercos drives as well as AS-i actuators to the defined safe state.
This way, the AS-i Gateway integrates AS-i as a second field device level besides the Sercos field devices (Lexium 62/Lexium 62 ILM and TM5/TM7 safety-related modules).
Up to five AS-i Gateways can be connected per Safety Logic Controller (which can be considered as one machine module or safety architecture).
Further Information
Also refer to the topic "Technical Information on the AS-i Gateway".
Environmental profile of the AS-i Gateway
The electrical and/or environmental characteristics of the AS-i Gateway may deviate from the characteristics of the Schneider Electric safety-related modules as it relates to your control system. Therefore, validate that the AS-i Gateway is integrated into environments that are suitable and therefore compatible with the Schneider Electric system.
Refer to the corresponding documentation or specification provided by Bihl+Wiedemann with the AS-i Gateway.
WARNING
INOPERABLE EQUIPMENT
Verify that all of the electrical and environmental characteristics of the equipment meet the operating conditions and requirements of the embedded safety system.
Failure to follow these instructions can result in death, serious injury, or equipment damage.
AS-i/Sercos Data Exchange (I/O mapping of AS-i data)
From the perspective of the Safety Logic Controller application, an AS-i Gateway device is considered as safety-related 64 bit (8 bytes) I/O data area. These safety-related 64 I/O bits are exchanged between the AS-i Gateway and the SLC via openSAFETY over Sercos. Into this 64 bit I/O data area, safety-related AS-i data are mapped in a user-defined way.
In EcoStruxure Machine Expert - Safety and EcoStruxure Machine Expert, these 64 I/O bits are represented as a device object referred to as '8 Bytes Safe Sercos Data'. After inserting this device object into the EcoStruxure Machine Expert 'Devices' tree (under the gateway node), it provides access (read-only in EcoStruxure Machine Expert and read/write in EcoStruxure Machine Expert - Safety) to the safety-related AS-i data mapped to the device object and transferred from/to the AS-i Gateway.
Composition of safety-related AS-i data: by means of a special, device-specific algorithm, the AS-i communication telegram of each connected safety-related AS-i slave is permuted into one safety-related data bit per AS-i slave. This safety-related data bit can be mapped to the 64 bit I/O area (device object) in ASIMON. Standard (non-safety-related) AS-i slaves cannot be mapped to the '8 Bytes Safe Sercos Data' device object. Consequently, the device object provides status information of safety-related AS-i input slaves and control data for safety-related AS-i output slaves. Furthermore, other safety-related AS-i data (such as diagnostic or output enable bits) may be included, depending on the user-defined mapping.
Mapping of safety-related AS-i data: the safety-related AS-i data must be mapped to the bits of the '8 Bytes Safe Sercos Data' device object. This mapping is defined by the user in the Bihl+Wiedemann software ASIMON. A clear data mapping is a 1:1 mapping: AS-i slave 1 connected to AS-i circuit 1 is mapped to input or output bit 1 of the device object (depending on whether the slave is an input or output device). AS-i slave 2 is mapped to bit 2, and so on.
The present documentation is predicated on the best practice of a 1:1 data mapping application. Beyond this, the diagnostic status signals for the AS-i circuits 1 and 2 provided by the AS-i Gateway are assumed to be used, as well as enable output signals for the AS-i slave outputs are also assumed to be used. See chapter "Configuration of the AS-i functionality in ASIMON" for details.
Via openSafety over Sercos, the '8 Bytes Safe Sercos Data' device object is exchanged between AS-i Gateway, SLC, and LMC. In the SLC, the safety-related data bits can be read and written. This allows monitoring, evaluating and controlling the AS-i application in a safety-related way. In the LMC, the safety-related data bits are mirrored and can be read to inform the standard (non-safety-related) LMC application about the safety-related AS-i status.
Illustration of AS-i data mapping:
|
The following applies to the '8 Bytes Safe Sercos Data' device object:
The device object consists of 64 input data bits and 64 output data bits regardless of the number of AS-i input slaves and output slaves connected to the AS-i bus. Observe the last item in this list regarding unused bits.
The SafeGatewayOK status bit indicates the communication status via openSafety over Sercos. SafeGatewayOK = SAFETRUE means that communication between the SLC and the AS-i Gateway is possible.
AS-i circuit status bits: the AS-i Gateway provides one diagnostic status signal for each of both AS-i circuits. By mapping these status signals to input bits of the '8 Bytes Safe Sercos Data' device object, they can be used as status bits similar to the SafeModuleOK signal from TM5 safety-related modules.
The present documentation is predicated on the best practice application in which the status signals are mapped to the input bits 0 and 32: bit 0 = SAFETRUE, the AS-i Gateway then indicates that AS-i circuit 1 is communicating properly. Accordingly, bit 32 = SAFETRUE indicates correct communication on AS-i circuit 2.
Output enable bits: the present documentation is predicated on the best practice application in which you use one separate signal generated in the safety-related SLC application as enable signal for each of the output AS-i circuits. Map these enable output signals to the output bits 0 and 32 of the device object and process them accordingly in the ASIMON application. This way, the output bits 0 and 32 can be used similar to ReleaseOutput control signals from TM5 safety-related modules: via bit 0 = SAFETRUE, the AS-i Gateway enables the AS-i circuit 1 and bit 32 = SAFETRUE enables circuit 2.
After deducting two diagnostic status bits and two enable output control bits as described above, both the input and the output bit group provide 62 data bits each that can be freely mapped in ASIMON (to input or output AS-i slaves).
Standard (non-safety-related) AS-i slaves are not represented in the device object.
The entire device object, i.e., 64 input bits and 64 output bits, plus the SafeGatewayOK signal are transferred from/to the AS-i Gateway. The device object may contain unused bits, for example, if no AS-i data has been mapped to a safety-related bit or, in a 1:1 data mapping, if no AS-i slave is connected at this bus position. An unused input bit is not written by the AS-i Gateway and remains SAFEFALSE permanently. Writing an unused output bit in the SLC application has no effect on AS-i side.
The mapping of AS-i data to the '8 Bytes Safe Sercos Data' device object has to be done in ASIMON and can be determined using the ASIMON project documentation. You have to ensure that the correct data bits are used in EcoStruxure Machine Expert - Safety. Refer to the topic "Reading and Writing AS-i Data Bits in EcoStruxure Machine Expert - Safety" for details.
Notes on distributed automation systems
You are going to set up a highly distributed system by implementing:
an AS-i application executed by the AS-i Gateway using ASIMON, and
a standard LMC application using EcoStruxure Machine Expert, and
a safety-related SLC application in EcoStruxure Machine Expert - Safety.
By means of a safety-related checksum (ASIMON ConfigID), the Safety Logic Controller is able to recognize whether the configuration and loaded application of the gateway corresponds to the AS-i configuration stored in the EcoStruxure Machine Expert - Safety 'Devices' window.
However, there is no superordinate, controller-spanning verification instance (or compiler) that verifies whether the various logics (AS-i Gateway, LMC, SLC) in the distributed controller application interact correctly.
WARNING
UNINTENDED EQUIPMENT OPERATION
Verify the interaction between the applications programmed for the AS-i Gateway (with its connected I/O devices) and the PacDrive 3 application (LMC and SLC programs).
Verify the mapping of AS-i I/O data to the '8 Bytes Safe Sercos Data' device object and the use of AS-i input/output data bits in the safety-related SLC application.
Be sure that the functional testing you perform comprises the entire system including the AS-i Gateway and I/O slaves, and corresponds to your risk analysis, and considers each possible operating mode and scenario the safety-related application should cover.
Observe the regulations given by relevant sector standards for the distributed automation system.
Use appropriate safety interlocks where personnel and/or equipment hazards exist.
Failure to follow these instructions can result in death, serious injury, or equipment damage.
In particular, the total safety response time of the entire system has to be inspected and verified precisely as the integration of the AS-i field bus with connected AS-i slaves extends the total safety response time calculated using the 'Response Time Calculator' in EcoStruxure Machine Expert - Safety.
WARNING
UNINTENDED EQUIPMENT OPERATION
Verify that the safety response time of the entire system includes the response times specific to the AS-i Gateway with its connected AS-i I/O devices.
Validate the total lag-time of the system and thoroughly test the application controlling for lag-time.
Failure to follow these instructions can result in death, serious injury, or equipment damage.
As the AS-i Gateway does not only provide gateway functionality between Sercos and the AS-i field bus but also implements control functionality for its connected AS-i slaves, it can be classified in a PacDrive 3 system between the control level (where LMC and SLC are located) and the field device level.
Illustration of PacDrive 3 system levels
Safe Logger Diagnostics
As any other Sercos subscriber, the AS-i Gateway uploads diagnostic Sercos-compliant messages to the LMC. These diagnostic messages are logged by the Safe Logger and the Message Logger.
The format of AS-i Gateway diagnostic messages in the logs slightly differs from the regular Sercos subscriber messages. The Message ID of AS-i Gateway messages is always EF01 hex.
In the 'Info 1' field of the Safe Logger, the error number reported by the AS-i Gateway is specified. Refer to the Bihl+Wiedemann documentation for details and remedy procedures for the reported error codes.
Further Information
Refer to the Safe Logger User Guide for further details.
Gateway Diagnostic Bits
The AS-i Gateway provides diagnostic bits which can be read and evaluated in the standard EcoStruxure Machine Expert application. Refer to the topic "AS-i Gateway Diagnostics" for further information.
The following scenarios can be implemented when integrating AS-i Gateways into Schneider Electric embedded safety systems:
Modular machine composed of/controlled by one LMC, one SLC, and one AS-i Gateway (with its AS-i I/O slaves). The SLC covers one safety-related architecture.
Modular machine composed of/controlled by one LMC, one SLC, and several (up to five) AS-i Gateways (each with its AS-i I/O slaves).
If several AS-i Gateways are connected to the Sercos bus, one SLC can monitor several AS-i safety-related architectures. As a consequence, a safety-related request from one AS-i safety-related architecture (coming from e.g., an AS-i emergency stop command device) can result in the entire SLC architecture with all contained safety-related drives and the AS-i field bus circuits assuming the defined safe state.
Further Information
Refer to the topic "Use case: several AS-i Gateways in one SLC Safety Architecture" for details.
