www'OpenLicenseSociety'org

1
Lessons from developing the OpenComRTOS
distributed Real Time Operating Systemusing
formal modeling techniques VVSS2007 - 23 Maart
2007

• www.OpenLicenseSociety.org
• www.melexis.com
• Unifying and systematic system development
  methologies
• with trustworthy embedded components
• Eric.Verhulst_at_OpenLicenseSociety.org

2
Outline

• Context and motivation
• Target of Open License Society
• Unified Systems Engineering Process
• Need for trustworthy components
• OpenComRTOS project
• Goal
• Why formal methods
• Results
• Trustworthy and better components

3
Embedded Systems

• Roof
• Rain sensor
• Light control
• Sun roof
• Interior Lighting...

• Climate
• Control panel
• Flap-Control
• Blower motor

• Seat
• Seat position
• Occupancy Sensor
• Control panel
• FANS

• Door
• Window lifter
• Central locking
• Switch detection
• Mirror adjust

• Steering wheel
• Cruise control
• Wiper
• Turning lights
• Radio
• Telephone...

• Front Module
• Lights

• Instrument cluster
• Parktronic
• Clock display
• Switches...

• Chassis
• Tire pressure
• monitoring

• Engine
• Sensors
• Small motors...

4
The Wall of Complexity challenge

• Products become systems
• Smart systems with 10s of distributed processors
• Embedded systems are essential and life-critical
• High quality, high reliability, scalability and
  security
• High level of safety, fault-tolerance, graceful
  degradation

• Murphys law
• things going wrong is a matter of probability
• and the odds are getting worse
• Business context
• Cost-efficient Competitive
• Upgradeable

• Trustworthy Components
• Formally developed and validated SW IP
• Engineering vs crafting
• Rid of unnecessary complexity and legacy
• Higher quality, less life-cycle costs, higher
  added-value

5
Evolutionary Systems Engineering
6
(No Transcript)
7
(Software) Engineering Process Flow
Configuration and Release Management
Peer Review
Fault Cases
Implementation
Implementation Design
Simulation
Project Management and Tracking
Requirements Specifications
Validation Test
Release
Architecture Design
Unit Test Design
Integration
Test cases
8
Process Flow Deliverables
Phase1
Phase2
Phase4
Phase3
Firmware Development
System Integration
System Validation
System Maintenance
Requirements Capturing
Specifications Capturing
System Architecting
FMEA FTEA
Safety Specs
Packaging Specs
HW Specs
Firmware Architectural Design
Firmware Implementation and Test
Firmware Maintenance
System Specifications Analysis
Firmware Validation
Firmware Integration
Firmware Specs
System Requirements
System Requirements
Firmware Released Source Code System Test
Results
Firmware Released Source Code
Distribution Validation Results
System Specifications (Normal Case) Test
Cases Fault Cases
System Requirements
Firmware Specifications Test Cases Fault
Cases
Firmware Architectural Design Test procedures
Firmware Beta Source Code Test results User
manual
System Modeling Simulation Architecture
Firmware Updates
Generated as single doc from OpenSpecs repository
Can be single doc
9
Generic Open-Comm-RTOS
10
Formal modeling for developing OpenComRTOS

• Goal
• Develop Trustworthy distributed RTOS
• Follow OLS SE methodology
• Formal verification analysis formal modelling
• Scalable distributed RTOS
• Verify benefits and issues of using Formal
  Modeling
• Why do we need formal techniques?
• How precise is the engineers brain?
• How precise is the managements brain?
• How precise can we define requirements?
• How precise can we define specifications?
• How precise can we  write  software?
• How precisely do we know all dependencies?
• How sure can we be of the end-result?

11
Can we trust our mind ?

• How many  F  did you find ?

FINISHED FILES ARE THE RE SULT OF YEARS OF
SCIENTIF- IC STUDY COMBINED WITH THE
EXPERIENCE OF YEARS
Did you see the similarity with source code
(debugging) ?
12
Formal modeling for developing OpenComRTOS

• Funded RD project (IWT, Flanders)
• Lancelot Research management, commercialisation
• Open License Society technology development
• University Gent (INTEC, Prof. Boute) formal
  modeling
• Melexis co-sponsor and first user (16bit uC)
• GUI tools
• graphical modeling/development environment
• University Berdyansk
• Goal
• Develop Trustworthy distributed RTOS
• Follow OLS SE methodology
• Formal verification analysis formal modelling
• Scalable distributed RTOS
• Verify benefits and issues of using Formal
  Modeling

13
Formal modeling tools

• Default mathematical approach
• Correctness by proof
• Labor and time intensive
• Needs specialists
• (Human) Error prone process
• Tools needed
• State space is exponentially large
• Issues always in  hidden corners 
• Allow incremental process
• Requirements
• Support state machines
• Support concurrency and communication
• Low notational barrier

14
Formal modeling tools selected options

• Investigated
• SPIN, B, CSP (FDR), TLA/TLC
• Outcome of process
• SPIN OK, initially preferred, good documentation,
  wide user base, but very C-like style
• CSP hard notation, FDR not readily available
• B waiting for Event B, incremental approach and
  compositionality very good
• TLA/TLC
• Based on Temporal Logic
• Mathematical notation, but standard
• Works for any domain (SW, HW, )

15
Benefits of TLA/TLC

• TLA/TLC home page on http//research.microsoft.co
  m/users/lamport/tla/tla.html
• Initial models reflected programming style
• Thats the way the mind works (after being
  conditioned )
• gt 28 successive models from 2 pages to 25 pages
• Initially very abstract, neglecting details
• All successive models were correct, why ?
• Iterative, incremental process!
• Takes 15 minutes from one model to the next
• Interplay between software architects and formal
  modeling engineer
• Architectural model polluted by programming
  concepts
• Abstraction from TLA helped to find these issues
• Result much cleaner, safer and performant
  architecture
• TLA models do not prove software is correct (! ?)
• TLC proves that Formal Models are correct

16
Formally modeled

• TypeInvariant /\ ppool \in Adr-gt Packet
  \union NoData
• /\ PQ \in FIFO Port -gt
  Seq(Adr),
• WL Port -gt
  Seq(Adr)
• /\ chan \in val HLink -gt Packet \union
  NoData,
• stt HLink -gt
  "free","busy"
  
• /\ TxQ \in TxChan -gt
  Seq(Packet)
• \ /\ tstate \in UTask
  -gt"running","ready","wait4anS","wait4anR"

17
Results

• Need for either FIFO Buffer or WaitingList
• Both (abstract) models are the same
• Natural language is imprecise, semantics are
  context driven
• Benefits
• Infinite buffering until no more memory (for
  Packets)
• Overflow-free buffering

18
All RTOS objects variation on a theme
19
Results (ctd)

• Break-through results in well-known domain
• 100s of RTOS with such support
• 15 years of experience, 3 generations of RTOS
  design
• Typically CPU dependent, use of assembler and
  async operation
• Small, scalable, distributed and maintainable
  code
• SP(L0) lt 1000 machine instructions
• MP(L0) lt 2000 machine instructions
• Needs a few 100 bytes of data RAM
• Fully in ANSI-C, MISRA-C
• Runs on MelexCM (16 bit) and Windows
• Scheduling algorithm can be improved to reduce
  worst-case rescheduling latency and blocking time
• All RTOS objects are variations of a generic
   hub  object
• gt less but faster code 5 KBytes vs. 50 KBytes
  before

20
Issues with TLA/TLC

• Needs a few months to get the right modeling
  style (especially concurrency)
• TLC declares critical section over all actions
• In RTOS must be minimal
• Requires good know-how of target processor
• Why cant FM not give the minimum critical
  sections?
• State Space is exponential
• Millions of states for small application test
  model
• Might need hours to check
• Tracing illegal states not always trivial

21
Key observations

• Successive iterations evolutionary
• gt 28 successive models from 2 pages to 25 pages
• Initially very abstract, neglecting details
• All successive models were correct, why ?
• Iterative, incremental process!
• Takes 15 minutes from one model to the next
• Interaction and abstraction
• Interplay between SW architects and formal
  modeling engineer
• Architectural model polluted by programming
  concepts
• Abstraction from TLA helped to find these issues
• Formalised thinking
• Much cleaner, safer and performant architecture
• Caveat FM do not prove software is correct (! ?)
• Proves that Formal Models are correct

22
How it really works teamwork
Requirements
How ?
Concept
Specifications
Informal Models
Validation
Test and profiling
Discuss, think, review
Implementation Models
Formalise !
Formal Models
23
Summary

• Open License Societys approach is about
  formalised thinking
• The essence is the SE process
• not the tools, but they help a lot
• The benefits are things being done better
• More clean, safe and performant architectures
• Contacts eric.verhulst_at_OpenLicenseSociety.org