Rules for SIL allocation for tasks in Safety-critical applications and partition sharing

Considering a safety-critical application, composed of several tasks, I have the following question:

Is it possible to have tasks of different SILs in an application, or are all tasks the same SIL? I know that in HW it is possible to have a system of a certain SIL actually composed of subcomponents of different SIL. IEC 61508-2, sec 7.4.3 presents the rules to combine subsystems of different SILs to form a system of a greater SIL than the composing parts.

If it is possible, what are the rules to combine? References are very helpful. For example, can a task of SIL 2 be the input for a task of SIL 3?

Thanks and good 开发者_Python百科luck,

---

Yes it is possible. I recommend reading part 3 of latest version of IEC 61508 (IEC 61508-3:2010) Appendix F, ‘Techniques for achieving non-interference between software elements on a single computer”, it’s only 5 pages, but very informative. It outlines methods for achieving spatial and temporal independence of software modules with differing SIL levels.

As said earlier in this link, operating systems such as PikeOS and Vxworks should provide this partitioning; I do know SafeRTOS, which has been certified to IEC 61508, does provide this type of partitioning as standard.

---

You should look at systems based on ARINC 653 (and DO-297) or equivalent. Partition-based OSes are designed to answered this kind of need. I mean PikeOS, VxWorks, Integrity ...

---

As I said : ARINC 653 compliant RTOS (for aircraft) is exactly targeted towards this goal. DO-178B (the equivalent to IEC 61508 or ISO 26262 or Def-Stan 55/56) require a segmentation in space and time between partitions or different software assurance level (for you, SIL level). You may find equivalent systems for your specific market. For linking different levels, there are inherent difficulties from the low level layers and communication channel. You will have to prove the determinism of your system at the higher level of security/safety/reliability (meaning the most difficult to obtain). Thus, communication could not be blocking, RTOS have to be certified to the higher level, ... This is taken into account in partition based RTOS, like ARINC 653 equivalent. You may also have success with MILS Linux or virtualized systems (= hypervisors like XEN, OKL kernels)

---

You can combine SW modules with different SIL level, even if the Indipendent Safety Assessor will analyse you code deeply. The principle is simple: you have to demonstrate that a lower SIL module can't influence a greater SIL module. To achieve this, you have to keep in mind that a lower- SIL-function can call a greater-SIL-function, but the opposite must be strictly avoided. In this scenario, to exchange data between two modules with different SIL level, you need a third module with a SIL level equal to the higher that provides to both the API to exchange data. Example: - a SIL3 task (T1) implements a fail-safe application protocol. - a SIL0 task (T2) implements the TCP/IP stack, used as transport layer of the application protocol. Of course, T1 and T2 have to exchange data in both direction. You need a third task (T3), at least SIL3, that provides the inter-task communication API (e.g. some queues management functions). In this way either T1 than T2 call only the functions of T3 (that is SIL3) to exchange data.

A typical example of this kind of mechanism is the so called "blackboard", used in avionics application.