Alain Girault, Avinash Malik and Zoran Salcic Design and Implementation of GALS systems Synchron, November 2011

 Reactions to the events and interaction with the physical environment (timing constraints)  Execution on the computer platform (its timing, resource and non-functional constraints) 2 Embedded Systems – Challenges Physical world Computing platform Embedded system Application

Control box Camera Sensor Mobile and fixed supervisor Network Control Box System server Video archiving server Control Box Video and other sensors BT BTT 3 Smart Distributed Surveillance System (SDSS)

 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) 4 System Component – Control Box Control Box BTT

 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 5 Requirements on Design, Specification and Programming Language(s)

6 Our current approach – GALS-centric GALS model (static or dynamic) Static (fixed number of concurrent behaviours) Dynamic (time-varying number of concurrent behaviors) SystemJlibGALSDSystemJDGALS New Language (includes Java) Library and run-time support (C/C++)

 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) 7 Language-based Approach

ENVIRONMENT R11 R12 CD1 R21 (Simple) CD2 R31 CD3 R32 R321 R322 SystemJ Program/System Java1 SystemJ 1 Java2 Signal ASignal BSignal CSignal D E Signal F Ch C12 Ch C32 Ch C23 Signal tosend  Graphical equivalent of SystemJ program (Static) 8 SystemJ Program Example

SystemJ kernel statementsMeaning 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 9 SystemJ (static subset) – The Kernel Statements

SystemJ kernel statementsMeaning 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 channel10 SystemJ (static subset) – The Kernel Statements

DSystemJ kernel statementsMeaning 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 C11 DsystemJ (dynamic set) – The Kernel Statements

ENVIRONMENT R11 R12 CD1 R21 (Simple) CD2 SystemJ Program/System receive print Signal S Signal A Ch CH SystemJ Simple Program Example  R11 waits on presence of signal S  Then emits A to trigger R12 to send a message to CD2(R21)  R21 receives and prints the message12

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); } 13 Interface declaration Inputs, outputs, channels Clock domain CD1 Clock domain CD2 Synchronous reaction R11 Synchronous reaction R12 Java data call SystemJ Simple Program Example

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 avedonCode on strange-love

D-SystemJ vs. other languages and libraries Languages Libraries Process forking SR- constru cts Asynch- constructs MobilityFormal - MoC Heteroge- neity Starva- tion MPI No YesNo Yes RML Yes No Yes No Occam-pi YesNoYesNoYesNoYes Erlang/ Salsa/Scala YesNoYesPartialNoYesNo X10(IBM) YesPartialClocks onlyYesNoYes Actor foundry No Yes No Jade YesNoYes NoYes SystemJ NoYes NoYes No DSystemJ Yes

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).17

libGALS Program  Signals and channels in libGALS systems18

libGALS Positioning19  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

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 drivers20

libGALS API API Function NameDescription createClockDomainCreate a clock domain createReactionCreate a reaction within a clock domain create[Signal | Trap]Create an instance of a signal or a trap startClockDomainStart running a clock domain initReaction/ endinitReaction Initialize a reaction and end initialization of the reaction getArgumentGet an argument passed to the reaction endReactionEnd 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 | sustainEmit/broadcast (or sustain) a signal presentCheck if a signal is present pauseEnforce end of tick for a reaction awaitWait for the presence of a signal21

libGALS API22 API Function NameDescription [strong|weak] abort/endAbort Start and end of a preemption block; preempt if monitored signals are present suspend/endSuspen d Suspend a reaction by one tick if a monitored signals are present setTrap/endTrapSet and end the scope of the trap exitTrapExit the trap, the reaction will jump to the end of the trap scope fork/joinFork out children reactions and wait for join of the children reactions AND,OR,NOT,REPForm a combined signal expression valueAcquire the value of a signal pre[Value]Get the presence status and value of a signal in the previous tick createChannelCreate a channel connecting two clock domains send/receiveSend and receive data between reactions in different clock domains via a channel

SystemJ Compilation and Execution Strategies23 Single- threaded Java code (no networking ) J2SE, J2ME, Squawk, Dalvik, specialized, JOP Platforms with separated CRCF and JCF SystemJ/DSystemJ program SystemJ compiler – front-end (Lexer and Parser Abstract Syntax Tree – AST Error Checks AST2AGRC AGRC AGRC optimizations Optimized AGRC JVM only platforms Java back-end code generation Standard Java byte codes Standard + reactive Java byte codes RJOPSingle- threaded Java code (networking) Multi- threaded Java code (networking) Embedded Systems platforms AGRC optimization for ESP and separation of control and data oriented code JCF Java byte codes CRCF code Tandem Virtual Machine (TVM) Tandem Processors (TP) Hybrid processors (GALS- JOP, JOP-Plus) Heterogeneo us Multicores (HMP, HMP- JOP, 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); } >< reaction M(:){ receive C; } >< reaction N(:){ receive C; } C_R1_ask C_M1_res C_N1_res C_R1_data C_N1_ack data ack Init Ask Data ask resp

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

 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)29 Building/testing and debugging Complex Software Systems

Building Complex Software Systems30 SystemJ Program 1 SystemJ Program 2 Dedicated Drivers Other programs Complex Software System Operating System PHYSICAL ENVIRONMENT 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 31 SystemJ program/DUT Environment emulator and observer (clock domain) Existing clock domain Test- bench channels New reaction to communicate with test-bench Test-bench = SystemJ program = DUT + EE (CD)

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 32 SystemJ program/DUT Environment emulator and observer (system) EE Test-bench = DUT +EE They communicate through signals Operating System Test-bench signals

 Distributed systems can be composed without changing individual SystemJ programs 33 SystemJ Program SystemJ Program Other programs Computer 1 Operating System Core 1 Core 2 Computer N Operating System SystemJ Program PHYSICAL ENVIRONMENT NETWORK Building Distributed Systems

 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 Conclusions

 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 On-going and Future Work

Thank you! 36