Automatic Derivation, Integration, and Verification of Synchronization Aspects in Object-Oriented Design Methods Automatic Derivation, Integration, and Verification of Synchronization Aspects in Object-Oriented Design Methods DARPA Order K203/AFRL Contract F C-3044 Principal Investigators Matt Dwyer John Hatcliff Masaaki Mizuno Mitch Neilsen Gurdip Singh Department of Computing and Information Sciences Kansas State University

Problem Description Embedded systems are growing in complexity and developers are looking towards OO technologies to manage that complexity Design methods for OO do not treat synchronization effectively Embedded systems software is multi-threaded for performance reasons –System correctness relies on correct synchronization of multiple activities Synchronization design/implementation is low-level and platform specific –Error prone and not reusable

Project Objectives III. Automatic verification of critical safety and liveness properties of woven embedded code … domain-specific model-checking engines … built on previous DARPA work – Bandera environment II. Automatic derivation and weaving of synchronization code … multiple language and synchronization targets (Java, C++, monitors, event service,etc.) … weaving & optimization via abstract interpretation and program specialization techniques I. Provide high-level, modular specification of global synchronization aspects … integrated with UML/RUP … formal specification via global invariants … language of composable invariant patterns … powerful, yet easy to use IV. Evaluation using BoldStroke OEP

Contribution to PCES Goals Invariant patterns enable reuse of synchronization “solutions” across multiple systems and languages Evaluate reduction in effort in context of BoldStroke OEP on controlled system development (class projects) Synthesis of “correct” synchronization implementations potentially eliminates a class of subtle coding errors –Evaluate potential for reducing errors and validation effort The overarching goal of the PCES program is novel technology and supporting engineering approaches that can greatly reduce effort to program embedded systems, while increasing confidence in the embedded software product.

Contribution to Relevant Military Application Apply our approach to BoldStoke OEP event service Event Service Application synchronization specification - Enhance event service to include synchronization support - Extract synchronization regions from existing Boldstroke applications and re-engineer them using our approach DoD Target System Studies - CAN based event service implementation - Seaborne (ST 2000) and Airborne (BQM- 74, MQM-107)

Project Tasks/Schedule Integration Verification Code generation Aspect code synthesis Synch Aspect language Key Tasks Non-synch Aspects Initial Optimized Full-scale Evaluation 5/01 5/02 10/01 10/01 + 5/02 10/01 + 5/03 5/02 + 5/03 5/01 (Java,C) 10/01 (CAN) 10/01 (ES)5/02 (ES) 11/02 (ES)+ 11/02 (CAN)+ 5/02 (CAN) 11/02 (Java)+5/02 (Java/C)

A Typical Synchronization Problem Flow policies in Boldstroke: control-push, data pull Sensor Logical Sensor Logical Actuator set event get event get

A Typical Synchronization Problem Flow policies in Boldstroke: control-push, data pull Sensor Logical Sensor Logical Actuator set event get event get Multiple sensors and actuators: Get single data value Get multiple values from single component Get multiple values via multiple calls to single component Get multiple values via multiple calls to multiple components Synchronization issues per Boeing OEP contacts

Gyroscope/Rudder System Logical gyroscope Buffer Logical rudder Logical gyroscope updates buffer Logical rudder reads position values from buffer and uses them to actuate the physical rudder

Gyroscope/Rudder System Logical gyroscope Buffer Logical rudder Logical gyroscope updates buffer Logical rudder reads position values from buffer and uses them to actuate the physical rudder : while (true) { : get new value from physical gyroscope : place value in buffer } while (true) { : get value from buffer : actuate physical rudder : }

Technical Progress Actors: Use Cases Classes: Use-Case Realizations Component Code Step 1: Synchronization specifications –via invariants and regions –Identify common idioms/patterns Global Invariant Specs Rational Unified Process (RUP)

Gyroscope/Rudder System Logical gyroscope Buffer Logical rudder while (true) { : get new value from physical gyroscope : place value in buffer } while (true) { : get value from buffer : actuate physical rudder : } wait until buffer is empty wait until buffer is full In G ++ Out G ++ Implicit Counters In R ++ Out R ++ Implicit Counters Assume each region has associated implicit in and out counters that are incremented as regions are entered and exited Step 1 Identify intended critical regions State a global invariant constraining occupancy of the regions

Invariants Invariants control entry and exit from regions by imposing constraints on counter values Exclusion(R A, R B ):(Out A – In A = 0) \/ (Out B – In B = 0) Pattern based approach: - template formula encoding a commonly occurring synchronization problem User never writes formulas but instead build invariants using a collection of global invariant patterns Invariant pattern repository on the project web-page

Gyroscope/Rudder Synchronization Logical Gyroscope Buffer ProduceConsume Produce Logical Rudder RGRG R Gyroscope Value Empty Buffer Slot Resource(R G,R R,0) Resource(R R,R G,1) Exclusion(R G,R R ) Resource(R G,R R,0) + Resource(R R,R G,1) + Exclusion(R G,R R ) Invariant:

Technical Progress Actors: Use Cases Classes: Use-Case Realizations Component Code Step 1: Synchronization specifications –via invariants –Identify common idioms/patterns Global Invariant Specs Coarse-Grain Solution Step 2: Automatic generation of coarse-grain generation solution – optimization using SVC Rational Unified Process (RUP)

Coarse-grain Solution Gyroscope Rudder Buffer C> …wait until B then execute C atomically …execute C atomically Step 2 From the invariant, guards for region enter/exit are generated automatically <await (In G == Out R ) && (In R == Out R ) -> In G ++> <await (In R < Out G ) && (In G == Out G ) -> In R ++> Semantics captured by high-level & language-independent intermediate representation Resource(R G,R R,0) + Resource(R R,R G,1) + Exclusion(R G,R R ) Invariant:

Complete Program Technical Progress Actors: Use Cases Classes: Use-Case Realizations Component Code Complete Program Fine-Grain Synchronization Code Step 3: Synch-code generation –C/C++ and Java - prototype released 9/01 -CAN: active monitor, replication -Tao event service (in progress) Complete Program Rational Unified Process (RUP) Step 1: Synchronization specifications –via invariants –Identify common idioms/patterns Global Invariant Specs Coarse-Grain Solution Step 2: Automatic generation of coarse-grain generation solution – optimization using SVC

Fine-grain Solution Gyroscope Rudder Buffer Call Gyro_Enter(); Call Gyro_Exit(); Call Rudder_Enter(); Call Rudder_Exit(); …monitors, rendezvous, semaphores, etc… Step 3 await and atomic statements are automatically translated to chosen synchronization mechanism Monitor Proc Gyro_Enter() … …; Proc Gyro_Exit() … …; Proc Rudder_Enter() … …; Proc Rudder_Exit() … …; Monitor

Fine-grain Solution using Tao Event Service Gyroscope Rudder Buffer Call Gyro_Enter(); Call Gyro_Exit(); Call Rudder_Enter(); Call Rudder_Exit(); Step 3 await and atomic statements are automatically translated to primitives in an enhanced version of the Tao Event Service Fine-grain Solution Implementation Tao Event Service Our enhancements for history and conditional events We believe that this will allow confident use of more sophisticated synchronization policies within the BoldStroke environment.

Event Service - Anonymous one-way communication between producers and consumers Supplier Proxies Subscription & Filtering Event Correlation Dispatching module Consumer Proxies Supplier Consumer - A consumer can subscribe to conjunction or disjunction of events - An event is pushed to all consumers that subscribe to it

Event service with synchronization - Enhance event service to include synchronization support Supplier Proxies Subscription & Filtering Event Correlation Dispatching module Consumer Proxies Supplier Consumer Synchronization

Translation for event-service In G ++> /* insert gyroscope value into buffer */ Logical gyroscope region: In R ++> /* read gyroscope value from buffer */ Logical rudder region: Supplier Proxies Subscription & Filtering Event Correlation Dispatching module Consumer Proxies Synchronization

Translation for event-service In G ++> /* insert gyroscope value into buffer */ Logical gyroscope region: In R ++> /* read gyroscope value from buffer */ Logical rudder region: Supplier Proxies Subscription & Filtering Event Correlation Dispatching module Consumer Proxies Publish Synchronization

Translation for event-service await (In G +1 <= Out R +1) && (In R == Out R ) /* insert gyroscope value into buffer */ Logical gyroscope region: <await (In G < Out R ) && (In G == Out G ) /* read gyroscope value from buffer */ Logical rudder region: Supplier Proxies Subscription & Filtering Event Correlation Dispatching module Consumer Proxies  In G ++  In R ++ > Counts the number of notifications Synchronization Publish Subscribe < > Control the number of notifications

Synchronization in Event Service Supplier Proxies Subscription & Filtering Event Correlation Dispatching module Consumer Proxies Supplier Consumer Synchronization - Exactly k semantics: an event is pushed to exactly k consumers - At most k semantics: an event is pushed to at most k consumers - At least k semantics: an event is pushed to at least k consumers Controlling the number of notifications: 1

Synchronization in Event Service Supplier Proxies Subscription & Filtering Event Correlation Dispatching module Consumer Proxies Supplier Consumer Synchronization - published(e): number of events of type e published so far - notified(e): number of notifications for event e pushed so far - Condition event: a predicate on published and notification counters - Event channel publishes condition events

Translation to event based solution In G ++> /* insert gyroscope value into buffer */ Logical gyroscope region: In R ++> /* read gyroscope value from buffer */ Logical rudder region: Condition events Simple events

Tao Real-time Event Service PushConsumer ProxyPushSupplier SupplierAdmin ProxyPushConsumer PushSupplier ProxyPushSupplier Dispatching

Modified Real-time Event Service PushConsumer ProxyPushSupplier SupplierAdmin ProxyPushConsumer PushSupplier ProxyPushSupplier Dispatching SynchAdmin synchronization event evaluate condition events publish condition events

Event service issues Event service issues Incorporate subscription changes Federated event channels Real-time scheduling with synchronization

Next Milestones ( months) Public distribution of prototype synchronization specification, code generation, and weaving tools Modify Tao Real-time event service to include synchronization support Re-engineer Boldstroke applications to use event-service based synchronization CAN-based event service Extend global invariant approach to address real-time synchronization properties (e.g., priority inversion) Provide evidence of correctness of synchronization policies implemented via event channel Integrate Bandera to check safety/liveness properties

Collaborations Stanford (SVC) Berkeley (Bane, Banshee) MIT (analyses to optimize weaved code) Grammatech, Inc. (slicing/verification techniques) Collins, aJile systems (JEM boards) Honeywell (challenge problems from avionics) Boeing (BoldStroke OEP) Kvaser, AB (CAN Kingdom = CDA 101/11) Seaborne Targets Engineering Lab (CDA 101) National Marine Electronics Association (NMEA)

Technology Transition/Transfer Boeing BoldStroke applications CDA 101 based Target Systems –Seaborne Targets: ST 2000 –Airborne Targets: BQM-74 MQM-107 Commercial Applications –NMEA 2000, CanKingdom - standards for real- time networking –Precision farming, industrial automation

Program Issues Repository of embedded systems applications illustrating the problems to be addressed Program meetings provide little time for technical interchange –i.e., identifying future collaborators Involvement of more industrial participants to provide challenge problems –i.e., need more than code and documentation

Funding Profile and Financial Expenditures to Date We are burning our Salary/IDC at 100% –Due to a clerical error certain charges made against the project have not hit the project account –It may appear that we are underspending, but back-charges will hit within the next month. We are burning our travel money at ~80% –Travel money from the 1 st funding period was shifted to the second period. This means that 100% burn of the second period’s travel money will appear as if we are underburning. –Note that due to this shift we had to pay for travel to the PCES kickoff meeting from non-PCES sources.