Design of a Real-Time Operating System
| Success Story|
|Keywords||real time, operating systems, IEC 61508|
This OpenComRTOS project started out with the goal to see how formal methods could be applied to embedded software development. The project targetted the design from scratch of a distributed Real-Time Operating System, so not a trivial tasks as it covers concurrency, protocols, local as well distributed state machines as well as boundary conditions of efficiency, hard real-time capability, scalability and other non-functional requirements. Five mains lessons learned are developed:
- Formal methods are not necessarily that hard to apply.
- Formal methods really shine when used as a design tool.
- Architecture matters. Code size still matters.
- Formalization is more important than going formal.
- Formalization pays off.
- The devil is in the details.
- Concurrent programming works.
- Learning from telecoms
The project made explicit how to select a specific formal method based on explicit need (TLA+ was chosen in this case) and also developed interesting metrics of success like code size, memory us, semaphore loops, interrupt latency.
- Description of a method for selecting a formal methods fitting the project needs (one method does not fit all needs). The selection process is based on a number of criteria like: human factors (e.g. model-checking technology easier to use than formal provers), widespread utilization, tool licence/maturity/performance, language expressiveness/readability/reusability/scalability/abstraction. The selection process is not based on an evaluation in the absolute but involve applying a subset of preselected candidated to a pilot case study
- Good lessons learned showing:
- that formalisation often brings performance in addition to correctness.
- that FM are useful as communication tool within a team to make assumptions explicit and have a clear semantics of all systemconcepts.
- Explicit metrics of success allowing to objectively compare designs produced with FM or with traditional methods.
- Addressing the compiler issue only slightly developed (model-checking of an implementation model)
- Model-checking could not be completed on all properties, switching to an automated theorem prover is considered
The success story is fully elaborated in the book .
Specific Deploy Contributions
N/A - not a Deploy project
Important next steps identified in the OpenComRTOS project are the following:
- Fault tolerance: while easy to program by hand, why not turn this into a compile time option? The architecture and code generators make it possible without changing the original application source code (assuming to be well written).
- Protocol composition: similarly, code generation from higher level specifications can generate application protocols as reusable blocks.
- Distributed priority inheritance: this was already implemented and was released in v.1.4.
- Asynchronous services: while already in place with single processor support, asynchronous versions of the task interaction services are a tough challenge for the semantics and the resource constraints of the embedded world.
- General resource scheduling: embedded systems are becoming less static and hence priority based scheduling of CPU time is no longer sufficient to guarantee a predictable Quality of Service. We have the concepts in place to extend the scheduling to all kinds of resources, even if the available resources might not be sufficient to satisfy all demands simultaneously.
- Dynamic code: This is a very tough requirement in distributed heterogeneous and resource constrained embedded systems. Using a formalized approach, we developed a solution that allows us to execute any binary code as a normal real-time task on any C programmable processor requiring just a few KBytes. In combination with distributed component based services, this is a powerful mechanism for diagnostics, encapsulating legacy code, fault tolerance and many more applications.
- ↑ E. Verhulst, R.T. Boute, J.M. Sampaio Faria, B?H?C? Sputh, V. Mezhuyev, Formal Development of a Network-Centric RTOS, Springer, 2011</name>
<ref> tag with name "OpenLicenceSociety" defined in
<references> is not used in prior text.