Transcript Design and Implementation of Globally

Design and Implementation of GALS
systems
Alain Girault, Avinash Malik and Zoran Salcic
Synchron, November 2011
2
Embedded Systems – Challenges

Reactions to the events and
interaction with the physical
environment (timing
constraints)
Physical world
Embedded system
Application

Execution on the computer
platform (its timing, resource
and non-functional
constraints)
Physical world
Computing platform
3
Smart Distributed Surveillance System
(SDSS)
Video
archiving
server
System server
Mobile
and fixed
supervisor
Network
Control Box
Control box
BTT
Control Box
BTT
Control Box
BTT
Control Box
BTT
Camera
Sensor
Video and other sensors
BT
4
System Component – Control Box

JPEG decompression

Motion vectors calculation and other image related algorithms
for single camera

Detecting objects in the FoV and tracking the biggest object

Track other object on operator request

Sensor fusion

(Virtual) Tripwire implementation

Communication with neighboring cameras

Handover/takeover implementation

Communication with operator

Mode transition (Auto-Manual-Auto)
Control Box
BTT
5
Requirements on Design, Specification
and Programming Language(s)

How to describe and design such complex systems?

System design language plays the key role

Language requirements
 Concurrency – synchronous and asynchronous
 Simple and reliable synchronization and communication
 Behavioral and structural hierarchy – modularity and
refinement
 Scalability
 Formal semantics - verifiability
 Shift from static to dynamic - change of system configuration
6
Our current approach – GALS-centric
GALS model (static
or dynamic)
Static (fixed number of
concurrent behaviours)
SystemJ
libGALS
New Language (includes
Java)
Dynamic (time-varying
number of concurrent
behaviors)
DSystemJ
DGALS
Library and run-time
support (C/C++)
7
Language-based Approach

Based on formal MoC - GALS (Globally
Asynchronous Locally Synchronous)

SystemJ = Java embedded into concurrency and
reactivity constructs

SystemJ = Java + Esterel +CSP
 Java - for object oriented modeling and algorithmic parts
 Esterel - for synchronous concurrency with reactivity and
safe communication of synchronous behaviors
 CSP - for asynchronous concurrency, message passing and
safe communication of asynchronous behaviors

DSystemJ = SystemJ + Dynamic creation + Mobility
(π-calculus)
8
SystemJ Program Example

Graphical equivalent of SystemJ program (Static)
ENVIRONMENT
Signal A
Signal B
Signal C
R11
Ch C12
E
Signal
R12
F
R21
(Simple)
R31
Ch C32
Java1
SystemJ
1
Java2
Signal D
R32
R321
Ch C23
Signal tosend
R322
CD1
CD2
SystemJ Program/System
CD3
9
SystemJ (static subset) – The Kernel
Statements
SystemJ kernel statements
Meaning
pause
Consumes a logical tick
[output][input][type]signal S
Signal declaration
emit S[(exp)]
Emitting a signal
p1;p2
Sequential statements
while(true) { p }
Infinite loop (temporal)
present (S) { p1 } else { p2}
Conditional statement
[weak]abort([immediate]S){p}
Watchdog
await (S)
Wait until signal present
1
0
SystemJ (static subset) – The Kernel
Statements
SystemJ kernel statements
Meaning
trap (T) { p1..exit(T);..p2}
Software exception
p1 || p2
Synchronous parallel operator
output [type] channel C
Output channel declaration
input [type] channel C
Input channel declaration
p1 >< p2
Asynchronous parallel operator
send C ([exp])
Sending on channel
receive C
Receiving on channel
1
1
DsystemJ (dynamic set) – The Kernel
Statements
DSystemJ kernel statements
Meaning
unique-name  CD([args])
Declare a named CD
unique-name  { }
Declare an un-named CD
run unique-name ([args])
Run CD unique-name
run #channel-name([args])
Run CD received via channel
channel-name
[input][output][type] channel C
Declare channel C
1
2
SystemJ Simple Program Example


R11 waits on
presence of signal S
Then emits A to
trigger R12 to send a
message to CD2(R21)
ENVIRONMENT
Signal S
Signal A
R12

R21 receives and
prints the message
R21
(Simple)
R11
CD1
receive
Ch CH
print
CD2
SystemJ Program/System
1
3
SystemJ Simple Program Example
system {
interface {
input int channel CH;
output int channel CH;
input signal S;
}
{
{ signal A;
{
await(S);emit A;
} || {
await(A);
while(true){
send CH(123);
pause;
}
}
} >< {
receive CH;
int i = #CH;
system.out.println(i);
}
}
}
Interface declaration
Inputs, outputs,
channels
Synchronous
reaction R11
Clock
domain CD1
Synchronous
reaction R12
Clock domain
CD2
Java data call
Example surveillance system in DSystemJ
PTZ cameras track a moving object indoors.
Two machines take part in the system (avedon –the camera controller and strange-love the code
repository)
Camera controller asks for code from the repository when a camera is attached (shown via input
signals) – channel based communication between CDs.
Camera controller code can be modified at runtime to account for changes in the tracking algorithm
etc.
Load balancing and resilience to fault is provided by the multiple servers providing source code for
GUIListener clients and the one-to-many communication protocol.
Surveillance system in DSystemJ
Code on avedon
Code on strange-love
1
7
What is libGALS?





A run-time library in C to support GALS MoC
Provides application programming interface to
describe libGALS: A Library for GALS
Programming constructs are intuitive – no low-level
details of communication and synchronization
Not only for single processor systems, but also for
multi core/multi-processing architectures
Ported to a number of operating systems (Windows,
Linux, RTEMS, µCOS II, pSoS, etc).
1
8
libGALS Program

Signals and channels in libGALS systems
Environment eg. Other software
components of the system
Inputs from the
Environment
Outputs to the
Environment
Clock Domain
Clock Domain
Reaction R1
Reaction R2
Signal
Reaction R3
Synchronizer
process
Channel
Reaction
Synchronizer
process
1
9
libGALS Positioning



libGALS is implemented by using OS services
Reactions and synchronizers are implemented using
libGALS itself and
Other OS services Other software communicates with
reactions via I/O functions
Reactions (synchronous processes)
Synchronizers
LibGALS
Host Operating System
Other
(asynchronous)
processes
or user-defined
drivers
2
0
libGALS Implementation







Data structures are established to implement
abstractions of clock domains, reactions, signals and
channels
Clock domain is a container which groups reactions
and signals and is registered with channels
Each reaction is a thread (task, pthread)
Synchronizer process enforces synchronization
between reactions within each clock domain
libGALS program is multi-threaded
Semaphores are used internally in libGALS (available
in all operating systems)  portability
Inputs and outputs implemented as functions –
interfaces to other software and device drivers
2
1
libGALS API
API Function Name
createClockDomain
createReaction
Description
Create a clock domain
Create a reaction within a clock
domain
create[Signal | Trap] Create an instance of a signal or a
trap
startClockDomain
Start running a clock domain
initReaction/
Initialize a reaction and end
endinitReaction
initialization of the reaction
getArgument
Get an argument passed to the
reaction
endReaction
End a reaction, called if the reaction is
not a child reaction
register[Emitter|Trap Register a process as a signal emitter
]
or a trap thrower
emit | sustain
Emit/broadcast (or sustain) a signal
present
Check if a signal is present
pause
Enforce end of tick for a reaction
await
Wait for the presence of a signal
2
2
libGALS API
API Function Name
[strong|weak]
abort/endAbort
Description
Start and end of a preemption block;
preempt if monitored signals are
present
suspend/endSuspen Suspend a reaction by one tick if a
d
monitored signals are present
setTrap/endTrap
Set and end the scope of the trap
exitTrap
Exit the trap, the reaction will jump to
the end of the trap scope
fork/join
Fork out children reactions and wait
for join of the children reactions
AND,OR,NOT,REP
Form a combined signal expression
value
Acquire the value of a signal
pre[Value]
Get the presence status and value of
a signal in the previous tick
createChannel
Create a channel connecting two
clock domains
send/receive
Send and receive data between
reactions in different clock domains
via a channel
2
3
SystemJ Compilation and Execution
Strategies
SystemJ/DSystemJ
program
SystemJ compiler – front-end
(Lexer and Parser
Abstract Syntax Tree – AST
Error Checks AST2AGRC
AGRC
AGRC optimizations
JVM only
platforms
Java back-end code generation
Standard Java byte
codes
Embedded
Systems
platforms
Optimized AGRC
AGRC optimization for ESP and separation of
control and data oriented code
Standard +
reactive Java
byte codes
JCF Java byte
codes
CRCF code
Platforms with separated CRCF and JCF
Singlethreaded
Java code
(no
networking
)
Singlethreaded
Java code
(networking)
Multithreaded
Java code
(networking)
J2SE, J2ME, Squawk, Dalvik, specialized, JOP
RJOP
Tandem
Virtual
Machine
(TVM)
Tandem
Processors
(TP)
Hybrid
processors
(GALSJOP,
JOP-Plus)
Heterogeneo
us
Multicores
(HMP, HMPJOP,
CMP,…)
Compiling DSystemJ programs
Asynchronous Graph Code
(AGRC) is used as an
intermediate format for
compilation.
AGRC is derived from
GRC used for compiling
Esterel.
Includes extra nodes to
represent asynchronous
CD forking (><) operator
Channel based
communication
∞ based termination
codes to describe
unresolved signal
dependencies.
Implementing rendezvous in distributed
environment
reaction R (:){
send C (2);
}
Init
C_R1_data
C_R1_ask
ask
><
reaction M(:){
receive C;
Ask
C_M1_res
ask
C_N1_ack
}
><
C_N1_res
resp
ack
reaction N(:){
receive C;
}
Data
data
Experimental results – SystemJ
LibGALS Vs SystemJ


LibGALS requires around 42% more lines of code to describe
the system
The loss in programming abstraction is gained in execution
speed
Experimental results DsystemJ
Vs DGALS vs JADE
2
9
Building/testing and debugging
Complex Software Systems

GALS (SystemJ) programs easily coexist each with
the other or with the programs written in other
languages

Condition: other programs “understand” signal
abstraction

Communication can be “direct” or through the
operating system (using sockets as universal
mechanism for external signals implementation)

Execution platform is “hidden” by the operating
system (can be single and/or multicore and/or
distributed)
3
0
Building Complex Software Systems
PHYSICAL ENVIRONMENT
Dedicated
Drivers
Signals
Complex
Software
System
Other
programs
SystemJ
Program 1
Operating
System
SystemJ
Program 2
Signals
Software Test-Bench 1

Environment emulator and observer of SystemJ design under
test (DUT) added as another clock domain

Minor modification necessary in the DUT
SystemJ program/DUT
Existing clock domain
New reaction
to
communicate
with test-bench
Test-bench = SystemJ program =
DUT + EE (CD)
Testbench
channels
Environment
emulator and
observer
(clock domain)
31
Software Test-Bench 2

Environment emulator and observer of SystemJ design under test (DUT)
added as another SystemJ program

No modification of DUT necessary

DUT and Environment emulator (EE) can run on different
processors/network
Test-bench = DUT +EE
They communicate through signals
SystemJ
program/DUT
Operating
System
Environment
emulator and
observer
(system)
EE
Test-bench signals
32
Building Distributed Systems

Distributed systems can be composed without changing individual
SystemJ programs
NETWORK
Computer 1
Computer N
Core 1
Core 2
SystemJ
Other
programs
Program
Operating
System
SystemJ
Program
Operating
System
PHYSICAL ENVIRONMENT
SystemJ
Program
33
Conclusions

GALS-based approach addresses needs of wide
range of future embedded and distributed systems

Formal MoC

Systematic design with models that can be analyzed

SystemJ/DSystemJ - Adoption of existing Java code

Flexibility – with or w/o OS

Range of target platforms – from standard (general
purpose) to specialized (customized)
34
On-going and Future Work

Time in SystemJ to make it more “real-time”
language

Formal analysis and verification of SJ/DSJ programs

Control processor ISA optimization

Marriage with Java processors

More....from Java to other languages
35
Thank you!
36