Features
Real Time Operating Systems for IEC 61508
In today’s world many potentially dangerous pieces of equipment are controlled by embedded software. This equipment includes cars, trains, airplanes, oil refineries, chemical processing plants, nuclear power plants and medical devices. As embedded software becomes more pervasive so too do the risks associated with it. As a result, the issue of software safety has become a very hot topic in recent years. The leading international standard in this area is IEC 61508: Functional safety of electrical/electronic/ programmable electronic safety-related systems. This standard is generic and not specific to any industry, but has already spun off a number of industry specific derived standards, and can be applied to any industry that does not have its own standard in place. Several industry specific standards such as EN50128 (Railway), DO-178B (Aerospace), IEC 60880 (Nuclear) and IEC 601-1-4 (Medical Equipment), are already in place. Debra Herrmann (Herrmann, 1999) has found a total of 19 standards related to software safety and reliability cut across industrial sectors and technologies. These standards’ popularity is on the rise, and more and more embedded products are being developed that conform to these standards. Since an increasing number of embedded products also use an embedded real time operating system (RTOS), it has become inevitable that products with an RTOS are being designed to conform to such standards. This creates an important question for designers: how is my RTOS going to effect my certification? This article will attempt to explore the challenges and advantages of using an RTOS in products that will undergo certification.
Introduction
Today, using a commercial RTOS is standard practice in many organizations. The benefits of using a commercial RTOS vs. rolling your own or going without one are many. For starters, it will help you structure your project into encapsulated software parts (tasks and memory blocks) and save your own development team a lot of time and effort from creating such infrastructure. With today’s tight budget and schedules, it is preferable to have your team work on application code for your product rather than infrastructure that supports your application. With the commercial RTOS, not only has this work already been done for you, and is available to you, but it has presumably undergone tens of thousands of hours of actual field usage making it much more mature and likely more reliable than any new code that would be written. In addition, using a commercial RTOS typically includes a rich development toolset that will help you to debug and monitor your applications. Having tools that are aware of the operating system and how it works is a tremendous advantage when trying to resolve complex design and debug issues.
In addition to the aforementioned reasons for using a commercial RTOS in any product, there are other advantages that a commercial RTOS can bring to safety applications. These include memory protection, safe communications and secure task scheduling. These services allow application programmers to readily include safety measures in their application. Operating systems that have these features will save work and reduce risk for their users. If operating systems do not have these features available, then the application developer must build these features into their application.
Memory protection provides application and operating system data protection against hardware faults and illegal writes. Many operating systems will isolate the address spaces of different processes running on the OS. This protection, combined with a hardware MMU will prevent one process from illegally writing over the data of another’s. This is a key feature that supports applications of different safety integrity levels to run on the same processor. Doing
so has tremendous advantages when going through a certification. First off, it allows you to identify non-safety critical tasks that do not need to be developed with the same level of rigor in terms of process and on-line diagnostics. This can greatly simplify the effort involved in the certification. Secondly, it allows you to use third party software in non safety critical areas without having to certify that software. Having to certify third party software creates extra challenges if you do not have the source code, lifecycle documentation, and/or cooperation from the vendor. Without this memory protection, you must either use other measures to assure this isolation, or consider all software to be safety critical and therefore subject to the requirements of the highest safety integrity level of your product. You must essentially assume that all software can corrupt the memory space of all other software and therefore must be treated as safety critical.