The Real-time and Embedded Systems Forum met from Wednesday October 24th through to Thursday October 25th co-located with The Open Group quarterly conference at the Grand Hotel Krasnapolsky in Amsterdam. The forum was divided into two sessions, the general open plenary session concentrated on safe software and safety critical systems, and the forum working group meetings. Both of the sessions in Amsterdam were open sessions.
The Wednesday session consisted of five briefings. Sessions included the Forum status update and overview , followed by four sessions related to Safety Critical software and systems, looking at the needs for standardization in this area and several practical experiences of implementing safe systems.
The working group meetings for the forum on the Thursday included a workshop on Safety Critical systems in the morning where a work plan has now been put together for 2002, and meetings of the Security working group and the group looking at Hard Requirements for Real-time Java®.
The Real-time Forum Working Groups are making good progress. The Hard Real-time Java requirements Group continues with the emphasis on FAA certification requirements (DO-178B). The Security for Real-time and Embedded Systems Group carried out a final review of RFI for Security for RT & ES. The Safety Critical Group prepared an outline of their approach and identified the relevant domains.
Looking forward to the 2002 roadmap, the planned deliverables for 2002 include test suites for POSIX 1003.13b Profiles 51 and 53, a certification program for POSIX Real-time profiles, a specification for Security for Real-time and Embedded Systems with reference implementations, white papers concerned with security and safety critical systems, and a new test and certification program in the area of Security for Real-Time and Embedded Systems.
The future meeting schedule for the forum is as follows:
Andrew welcomed everyone and explained that Martin Timmerman, the keynote speaker had been taken ill and was not able to attend at short notice. Due to this he gave an expanded talk on the current status of the Forum and plans for 2002.
Andrew explained that he has recently moved to a new role within The Open Group as Director of Certification, this meant he would be concentrating primarily on the certification aspects of the forum and transitioning the forum directorship. He then went through the agenda:
He moved onto the vision of the forum drawn from the 2002 forum plan -- that ultimately the forum is intended to grow the marketplace for everybody. The goals of the forum are:
Industry sectors in the scope of the forum include Industrial controls, Aerospace, Telecommunications, Defense, Medical/scientific, and Automotive control.
Presently there are 17 members of the forum, most of those being US based. There is a need to get more European participation. He ran through the opportunity of the forum before presenting the forum's scope that also included safety critical. He stressed that collaboration was the key and then gave a list of liaisons
Before reporting on the Austin, TX meeting last July Andrew introduced the forum co-chairs, Dave Emery, MITRE and Lt. Col. Glen Logan. Joe Bergmann reported on the work done by the Security Working group saying that it goes beyond the RT group. He then listed the working group champions, viz.:
A small discussion on security validation ensued at this point. He then showed a work plan submitted by Dave Emery for Safety Critical when Dave Emery gave a 30 sec. summary on it. He presented a slide on how the forum usually operates explaining that at this meeting all the sessions were to be open because of the travel restrictions of most member companies in the current business climate.
He then presented the roadmap looking forward to where the forum was going showing some deliverables for 2001/2002 such as:
The next meeting is to be in Anaheim, near Los Angeles in January 2002. He then mentioned in closing the following:
It is always good start with some definitions so what is Safety-Critical software?
These are not necessarily a complete list. We are talking about system failures, not software failures
Characteristics of a safety program
There are multi levels of hazards so the mitigation strategy should be based on the hazard and its severity. If something is not likely to cause loss of life then the requirement is much less stringent. Software can perform correctly but the system fails and vice versa
DO-178B is an example
You cannot talk about safe software only safe systems. In most safety systems there is a human in the loop and this is usually a good thing. More requirements are being put on computers to do things that humans used to do; this means that safety-critical becomes more and more important.
DO - 178b defines more about processes rather than specific behavior
Software verification gets the most attention because 80% - 90% of the money can go into it. Verification is the real key because that is where the money is.
Software verification
DO-178B section 6
You want to show that all the requirements that are allocated to software are mapped to points in source code. Also you should not have source code that is not being mapped to. You need to show that every instruction produced the right answer.
Traditional development will involve the following points:
The higher up you go in certification the more restrictive software becomes. Much of the higher level goes towards preventing errors at lower levels - thus no storage allocation is allowed at higher levels.
Certification is an iterative process and goes through these steps:
First you have to show that you did what you said you would do and then you must show that the results were what were expected.
There are two key cost drivers for safety critical software:
Impact of COTS
Because of cost there is a lot of interest in commercial software but it is not known as COTS rather SOAP.
The question is therefore how to achieve cost savings via reuse of COTS, without compromising safety?
If these 2 are met then there is a case to use COTS.
If you remember nothing else remember the following:
What can COTS developers do?
This is a big question to get to a common set of documents acceptable to many vendors.
If we can get it to this stage then it becomes "Open" and this means safety.
The technical man can say that he knows what he is going to get whilst the businessman knows what the costs are.
This is therefore a potential Open Group Agenda:
Advantages (+) and disadvantages (-) are:
The challenge is does The Open Group want to be involved in this way? We have to be able to justify it with ROI. It is a significant project. We can make a difference if use of COTS can reduce development costs, and reduce test and development times over doing it yourself.
This session was from LynuxWorks, an OS vendor, giving their experiences of working with a customer building a safety critical application. The agenda for the session was as follows:
He explained that the company had been around for over a decade focusing on two early events in the early 90s; Selected by IBM/NASA for Space Station
and HP licenses LynxOS as HP/RT for PA-RISC.
He went on to describe LynxOS highlighting the following points:
He started on an application example of a navigation system employed in the A340 Airbus. It incorporates FANS (Future Air Navigation System). He stressed the capacity problem in being able to fly aircraft closer together as well as navigate new routes. One of the objects of FANS is to enable an aircraft to change route without compromising the safety inherent in the original flight plan.
He showed a slide where the aircraft becomes a node in a communications network involving satellite plotting. The Aerospatiale ATSU (Air Traffic Services Unit); integrates all services dedicated to data communication between the aircraft and the air traffic centers, all the needed resources to implement the future ATN Network, as well as the present ACARS functions (Aircraft Communication Addressing and Reporting System).
He went on to discuss EADS Airbus requirements which included:
He described the LynxOS reliable process model allowing a spatial representation of the tasks running on the system and then showed a graph representing the deterministic behavior of the kernel. Here he stated the importance of what really distinguishes RTOSs is what happens to them under load.
Then he moved on to describe LynxOS's kernel architecture with sample sizes of the separate modules.
Dave Emery asked what the mapping was in the slide to the POSIX functionalities. Chris said it was not exact. Dave stated that one needed to be able to configure LynxOS to the POSIX functionality. Dave said that it was possible to end up with the whole thing. A discussion ensued about the need of threads vis-à-vis memory detection.
Chris then outlined the project process that included the following:
Dave asked whether the highest level of criticality went up to level A? Chris said only to level C.
He then presented a slide showing the DO178B software criticality levels which are:
He said that most of the demand was now for level A and level B. Then he went on to discuss the LynxOS software certification program saying that it assisted customer certification and acted as a foundation for customer tailoring. The documentation and testing they are providing is for the core part of the kernel. He said they had drawn the 'proverbial line in the sand' where the basic documentation and verification material has been prepared for the kernel common portion of the operating system. Those functions that are not processor independent or are called through the application software are not addressed. However, Customer Solutions is available to address these issues on a customer project basis.
They are providing the data and source code for what they call the kernel common:
He moved on to address the design data and software before looking at the verification data and customer solutions support. He concluded that people are putting more and more functionality into embedded systems. It is being seen in safety critical systems as well. The 3 main concluding points he talked about are:
Question:
How did you deal with the Aerospatiale contract commercially?
Answer:
We use a lot of the stuff developed for them generally now. In fact it was one of their requirements that this was so in order to make it more generally supported.
Question:
Have done an analysis in growth of safety-critical system?
Answer:
No
Question:
What do you do about h/w failure?
Answer:
We have built a lot of checks into the kernel
Is it healthy exercise to certify RTOS? Even though we know it's healthy why don't we exercise? It takes time, it costs money, and it is not fun. So what is involved in making RTOS healthy:
He continued with some very good analogies so why certify an RTOS? These are some of the reasons:
And Vance went on to give these reasons why one should use DO178B for certification:
DO178B has 3 basic areas of work:
He then went on to show where the time goes on a certification project before looking at the DO178B structure.
He said that a snapshot of DO178B could have the following points:
Next he considered common themes within DO178B and then reiterated the 5 levels of criticality, A through to E. 80% of all the systems on an airplane are level A or B.
He then showed some 20 or so data items in the software life cycle before considering the relationship between certified and certifiable. Thus:
He then ran through the top certification mistakes made by his company as well others that included:
He then questioned what the future for certification was? He felt it was increasingly required due to the convergence of standards. It would find increased use in DoD, nuclear and ground systems. There are now pre certified tools available.
He concluded with a very funny story about the 3 software teams.
Early reasoning can raise standards and reduce costs. He introduced himself and his company. He then stated that critical systems were those where reliability was more important than:
It is not just a question of "being more careful" when producing critical software. One has to be able to show, before there is any service experience, that a system will be safe enough. He said that everybody used formal languages however readable it is and said that a typical development process was one of an informal semi-opaque black box leading to precise object code.
Precise languages can provide a framework for precise reasoning; they are qualitatively different. Precision could be increased in requirements, specifications and code. He exemplified this by a pedestrian/traffic light/road example; here the fact that drivers stop at red lights is assumed but is not part of the system.
He gave some examples of systems that Praxis had developed in particular SHOLIS. Because this was the first project done Praxis recorded everything, including the number of commas changed and showed the results in a histogram displaying faults found versus effort.
In order to prove something you really have to think about what you are doing with the specification. The fact that you know you have to prove it means that you change the way you will write it.
He then turned to code. Programming languages are seductive because the code "looks" like mathematics. But lurking in the background there are all sorts of things such as program overflow etc. A precise programming language will amplify the value of activities such as reviews, allows static analysis and leads to early error elimination. SPARK is a precise programming language.
He then gave an example of why early error detection save a pile of money in certification. The results obtained during integration testing may differ from those obtained during unit testing.
He moved on to talk about MULTOS, which is for smart cards. Applications can be loaded on to the card. The CA had some unusual requirements. He went into quite a lot of detail about it.
He felt that some positive trends are improved tool support, model checking and "formality by stealth" (tools that have mathematical underpinning but do not hit you with it). Some negative trends are deliberate adoption of imprecision, done because it appears to make the job easier and because it conceals the hard stuff.
He concluded that you cannot retrofit quality, there is correctness by construction and formality by stealth has been successful.