Embedded Control System Software Design based on CSP

1
Embedded Control System Software Design based on
CSP

• Gerald H. Hilderink
• University of Twente
• The Netherlands

2
Contents

• Introduction
• Embedded Control Systems
• What we want from Concurrency
• Communicating Sequential Processes
• Why CSP?
• Control Software Design
• Research at Control Engineering
• Conclusions

3
Embedded Control Systems

• We have the tools to develop control models that
  are competent as executable simulation models
• but what about embedded software?

• Control systems are a class of real-time systems
  and usually embedded in a product.
• Control systems are concurrent systems.
• Control systems have a tightly relation between
  hardware and software in a constrained
  environment.
• Control systems are reactive, distributive, safe
  and robust.

4
Embedded Control Systems

• In the past
• CE had experience with CSP technology occam and
  transputers.
• At present
• CSP implementations should not be restricted to
  occam and transputers.
• Occam/CSP look-and-feel should also find his way
  in other industrial trends.

Mart
Oscar
Transputers
5
What we want from Concurrency
concurrent programs wait faster! Tony Hoare,
July 2001 at Microsoft

• Improving throughput, responsiveness,
  utilization, and
• If a system model can reflect the natural
  concurrency in the system it should be simpler.
• A powerful tool for simplifying the description
  of systems.
• Performance that spins out from the above, but is
  not the primary focus.
• A model of concurrency that is mathematically
  clean, yield no engineering surprises and scales
  well with complexity.

6
What we want from Concurrency

• Yet, concurrency is thought to be an advanced
  topic, harder than serial computing (which
  therefore has to be mastered first).

This tradition is WRONG!
7
Communicating Sequential Processes (CSP)
A mathematical theory (process algebra) for
specifying and verifying complex patterns of
behavior arising from interactions between
concurrent components. CSP has a formal, and
compositional, semantics that is in line with our
intuition about the way things work. original
untimed CSP by Tony Hoare (1985) updated
untimed CSP by Bill Roscoe (1999) updated
timed CSP by Steve Schneider (2000)
8
Why CSP?

• Encapsulates fundamental principles of
  communication.
• Semantically defined in terms of structured
  mathematical model.
• Sufficiently expressive to enable reasoning
  about, deadlock and livelock.
• Abstraction and refinement central to the
  underlying theory.
• Robust and commercially supported software
  engineering tools exist for formal verification.
• CSP is (parallel) architecture neutral
• Message-passing
• Shared-memory

9
Why CSP?

• Captures system descriptions at different stages
  in the software development process
• Specification
• Design
• Implementation
• After 5 hours teaching
• Exercises with 20-30 threads of control
• Regular and irregular interactions
• Appreciating and eliminating race hazards,
  deadlock, etc.
• We do not need to be mathematically sophisticated
  to work with CSP. That sophistication is
  pre-engineered into the model. We benefit from it
  simply by using it.

10
Processes
Process

• A process is a component that encapsulates some
  data structures and algorithms for manipulating
  that data.
• Both its data and algorithms are private. The
  outside world can neither see that data nor
  execute those algorithms! They are not objects.
• The algorithms are executed by the process in its
  own thread (or threads) of control.
• So, how does one process interact with another?

11
Processes
Process

• The simplest form of interaction
• two-way synchronized message-passing along
  channels.
• zero-buffered and point-to-point (ie. wires)
• Extended form of interaction
• sending (moving or copying) object over channels
• buffered channels (blocking/overwriting)
• shared channels
• call-channels, like Adas entry-accept message
  passing
• multi-way synchronized message-passing along
  barriers

12
CSP channel concept

• channel object

message
prod-cons / client-server
read/accept
write/call
Process A
Process B
Process A
Process B
(a) Data-flow modeling
(b) Object oriented
channel
read/accept
write/call
read/accept
write/call
Process A
Process B
Process A
Process B
System 1
System 2
Link driver
(c) Hardware (in)dependence
(d) Distributed and heterogeneous
13
Control Software Design

• Example CSP abstract design language

y
Controller
Plant
System Controller Plant
x,y
x
Communication Graph (e.g. Blok Diagram in 20-SIM)
S
a
b
c
y
A
B
C
A(a) C(c,y) S(a,b,c) D(e,d) B(b,c) E(x,e)
d
e
x
E
D
Composition Graph (shared topology)
S

A(a) ((S(a,b,c) B(b,c) C(c,y)) (E(x,e)
D(e,d))) B b?z ? c!f(z) ? B
A
B
C


E
D
14
Control Software Design

• Code Generation

CHANNEL a, d -- synchronization
primitives CHANNEL bbuf, cbuf, ebuf -- may
become variables CHANNEL xAD, yDA --
channels with link drivers PRI PAR A(a) PAR SE
Q S(a,b,d) B(b,c) C(c,y) SEQ E(x,e)
D(e,d)
Java, C, and C CTJ, CTC, and CTC
Abstract Design Language
Graphics with a tree-browser
Textual CSP for use with FDR
UMLable
15
Research at CE

• a new software platform based on CSP on which
  we build our embedded control software!

• Substitutes occam and transputer technology with
  modern programming languages and hardware.
• Based on Object-Oriented technology.
• Heterogeneity processes can run anywhere!
• Compositional and Scaleable managing
  complexity!
• Specifying, designing, and implementing
  concurrency and real-time behavior without
  discontinuities.

16
Research at CE
the new software platform

• OO/CSP model (advanced occam/CSP model in OO)
• CSP for Java, C and C libraries
• CSP abstract design language
• CSP extensions to UML ( RT-UML model)
• 20-SIM code-generation with CSP
• Other tools support

17
Research at CE
Communicating Threads

• CSP packages available for OO programming
  languages
• for Java and C (also C), called CTJ, CTC, and
  CTC
• using threads without programming with threads
  directly
• compact, simple, and elegant
• Implements processes, channels, and more
• compositional constructs PAR, SEQ, ALT
• updated prioritized parallel construct real
  PRI PAR
• improved alternative constructs fair ALT and
  unfair/fair PRI ALT
• notion of preference priority improving
  performance
• CSP kernel is embedded in the application
• OS independent (e.g. i386/DOS, i386/WINDOWS,
  i386/RTLINUX)
• runs on bare processors (e.g. PC104,TMS320/DSP).

18
Conclusions

• A new software development platform based on CSP,
  but beyond occam and transputers.
• CSP offers a formal approach throughout all
  stages of the software development process.
• CSP has compositional semantics WYSIWYG and
  Plug Play.
• CSP can simplify design in a elegant way.
• CSP abstract design language
• graphical specification and design
• visualizing design conflicts, potential
  deadlocks, priority inversion problems
• glue-logic between process orientation,
  object-orientation, and structured methods
• CTJ enables direct Java implementation of CSP
  design.
• Benefit from CSP simply by using our platform.

19
Questions

• www.ce.utwente.nl/javapp
• g.h.hilderink_at_el.utwente.nl

20
Embedded Control Systems

• Commercial tools support ECS as if!
• concurrency very artificial
• only for a specific class of systems, usually
  laboratory set-ups
• based on a highly sequential execution framework
  that inherits all the disadvantages of a single
  thread of control
• discontinuity between model and implementation
• The CSP approach supports ECS claim!
• concurrency more natural
• generic approach for a wider range of systems
• compositional, and highly scalable
• continuity between model and implementation

21
So, what is CSP?

• CSP deals with processes, networks of processes
  and various forms of synchronization/communication
  between processes.
• A network of processes is also a process so CSP
  naturally accommodates layered network structures
  (networks of networks).
• We do not need to be mathematically sophisticated
  to work with CSP. That sophistication is
  pre-engineered into the model. We benefit from it
  simply by using it.

22
CSP abstract design language
Communication relationships
Compositional relationships
channel communication
sequential composition
input guarded channel communication
parallel composition
prioritized parallel composition
output-guarded channel communication
equally-prioritized alternative composition
barrier communication
unequally-prioritized alternative composition
Special processes
channel input or accept
?
channel output or call
!
undefined relationship
joint barrier synchronization

parenthesizing or grouping relationship
recursive loop
?
23
Conclusions

• CSP diagram renders the blueprint of concurrent
  software architectures
• CSP diagram provides glue logic between
  structured methods and object-orientation
• UMLable
• High design freedom
• Mathematical analysis detecting design
  conflicts, deadlocks, and priority inversion
  problem