Meeting Regulatory Demands—Is There Help from the World of IT?


  • Page 1 of 1
    Bookmark and Share

Once upon a time in the early days of embedded systems, developers were tinkerers working on relatively small and dedicated projects—a braking controller, a vending machine, various factory automation projects. Now don’t get me wrong. These were not trivial; they had performance requirements, deterministic behavior demands, power constraints and much more.

By “tinkerers” I really mean that developers tended to go about their tasks in what was once called a “chaotic” approach. That is, without a clearly defined process or discipline. It was not so long ago, maybe ten years since I actually saw the statistics, when about 50 percent of projects still used their own in-house RTOS or even RTOSs developed from scratch on their own.

As the complexity and size of projects increased, tools were developed to meet the emerging challenges—source level debuggers, trace tools, logic analyzers (remember them?), event analyzers, dynamic and static analysis tools, multithreaded debuggers, multicore debuggers. The list is very long and much genius and much sweat were dedicated to keeping developers abreast of their challenges. Still, it seems that most of the effort was, quite understandably, reactive. Problems and challenges emerged and they were faced and mostly solved. Only seldom did an isolated voice cry out from the wilderness the word “process.” And even less often was heard the word “documentation” in regard to the word “process.”

That is now changing.

Software and systems developed for regulated application areas like aerospace, medical, automotive and for any electrical safety-critical applications, are required to conform to international standards. These include IEC 62304 for medical devices, IEC 61508 for safety-critical electrical devices, DO178 for the aerospace arena and many more. These standards do not simply require testing and certification of the finished system. They also specify and require documentation of the development process; they often provide specific requirements for development tools including design tools, testing and debugging tools and configuration management tools to name a few. All this must be complied with and documented as well.

It turns out that a number of practices and tools used in the IT world are being adapted for use by the embedded community to help meet growing regulatory and certification requirements. Additionally, some of the embedded practices known in the realm of DO178 are becoming familiar with developers engaged in other projects that nonetheless must be submitted to regulation and certification requirements equally as demanding. One of the latter of these is the preparation of software components such as RTOSs that are guaranteed “certifiable.” Only the final application can be certified by a regulator body, so it is not possible to purchase a “certified” RTOS, for example. What is possible is to have an RTOS that has already been part of a certified application/system. That means that with proper documentation accompanying the RTOS, the vendor can guarantee the customer that this part of his system will pass the certification process with no further effort on his part. Increasingly, since such components come with the required documentation, that documentation includes the development process and thus helps the customer step into the world and to continue following that process in his own project.

While embedded developers are familiar with requirements tracing, a more formal process of requirements engineering is beginning to appear. This incorporates requirements definition and management with a defined requirements specification structure, tracking through the code development process based on the high-level components of a system. Other types of tools, such as static and dynamic analysis, are being adapted to the needs of embedded development and to the process compliance and documentation demands of the standards and regulatory bodies.

Those companies contemplating entering this world would do well to check out not only the standards and process compliance demands ahead of time, but also what tools and “certifiable” components are available to help get started. Waiting until you are deep into a project and then deciding to apply such tools and practices is a recipe for disaster.

Be sure to visit our web site at for links from selected stories to additional information.