Traditional safety systems have a centralized architecture, meaning that a large processor unit runs hundreds of safety instrumented functions (SIF). Modern safety systems have a distributed architecture where multiple smaller processor units execute dozens of SIFs. Distributed safety systems offer many cost and maintenance benefits, but some users worry they’re harder to configure than a centralized safety system. I believe this worry stems from a couple easily clarified misconceptions.
Misconception #1: Configuring centralized systems is simpler since “everything” is in one place.
Reality: Even a centralized system logically divides the application program into manageable entities.
Most safety applications are split into management areas including:
A well-written application program will be modular whether in a centralized or decentralized system. This makes the application program easier to handle and test without significantly changing the configuration effort.
Well-designed safety systems have each SIF coded independently to facilitate testing, management of change, and traceability to the safety requirements specifications. Dividing the configuration in SIFs also aligns with both 61508 and 61511.
Coding SIFs independently simplifies testing, management of change, and traceability.
Misconception #2: Smaller logic solvers offer reduced I/O and complicate I/O allocation and peer-to-peer communication in distributed systems.
Reality: Expanded I/O accessibility and a tag-based approach simplify communication.
In a tag-based configuration approach, users only need to define the tag name for a signal (e.g. LT-101A). Unlike systems where the I/O reference is defined in terms of I/O card slot and I/O channel address, knowledge of the physical location of the signal is unnecessary, as allocation of inputs is automatic. Output channels are also referenced by tag, but they can only be driven locally; therefore, the module allocation follows output allocation. If needed, a signal can be shared with other logic solvers to drive outputs on a remote logic solver.
Combining tag-based configuration with electronic marshalling makes distributed systems even easier to configure. Most of the time, physical signals are not wired directly to multichannel IO cards. Instead, all the signals within an area are grouped and connected to a junction box (JB). That JB is connected via a multi-core cable to a marshalling panel and then to the multi-channel card.
For other types of communication (beyond input signals), the tag approach maintains consistent communication across different modules, different logic solvers, or even different safety networks.
Emerson has designed the DeltaV SIS with critical features configuration that make it easier to configure such as:
Built-for-purpose function blocks simplify configuration.
In addition, many users think a smart logic solver only has 96 I/O, so applications above 96 I/O require complex configuration to communicate among multiple logic solvers. A CHARMs smart logic solver (CSLS) eliminates this restriction. A CSLS has 96 local I/O, but all inputs are directly accessible to any CSLS in the local safety network, without the need to explicitly define peer-to-peer communication.
With DeltaV SIS, the user simply defines a tag for a parameter which is then referred from different modules by parameter name. The safety system creates the proper communication path automatically. Initial setup is simple, and modification is easy. To move a module from one CSLS to another, the user simply needs to move the SIS module and all references are automatically updated.
For more information on distributed safety systems visit the DeltaV SIS page at Emerson.com. Or feel free to leave a comment below to share your own strategies for simplifying SIS configuration.
The post Addressing Common Misconceptions in Safety System Configuration appeared first on the Emerson Automation Experts blog.