Automatic Derivation, Integration, and Verification of Synchronization Aspects in Object-Oriented Design Methods DARPA Order K203/AFRL Contract F33615-00-C-3044 Principal Investigators Matt Dwyer John Hatcliff Masaaki Mizuno Mitch Neilsen Gurdip Singh Department of Computing and Information Sciences Kansas State University http://www.cis.ksu.edu/santos

Problem Description Embedded systems are growing in complexity and developers are looking towards OO technologies to manage that complexity 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 Design methods for OO do not treat synchronization effectively

Project Objectives 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 II. Automatic derivation and weaving of synchronization code … multiple language and synchronization targets (Java, C++, monitors, semaphores, etc.) … weaving & optimization via abstract interpretation and program specialization techniques Here are the goals of the project in a bit more detail… We provide support for high-level modular specification of global synchronization. For us, a specification will be a global invariant that enforces certain policies for entering and exiting critical regions. One writes a spec in a very simple language of composable invariant patterns, and then these patterns are compiled down to first-order logic. The pattern language is powerful (we’ve used it to solve all the exercises in a couple of well-known concurrent programming textbooks), yet it is easy to use. Finally, the process of writing the specifications is integrated with RUP. <click>From the initial specification,<click> we’ll be able to generate synchronization code for multiple languages (e.g., Java, C++) and for multiple synchronization primitives (e.g., monitors, or semaphores). Generated synchronization code is automatically woven with core functional code using program specialization techniques. <click>After synchronization code is generated, it will be checked automatically check for critical safety and liveness properties (such as absence of deadlock) that are not captured in the global invariants. This checking is carried out using software model-checking tool called Bandera that we developed in a previous DARPA project. <click>Finally, we’ll be evaluating this approach using some military systems for networking target vehicles. 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 IV. Evaluation using Common Digital Architecture (CDA101) … a new standard for military target vehicle electronics

Technical Approach --- Invariant Patterns Users never write formulas but instead build invariants using a collection of global invariant patterns… Bound(R,n) … at most n threads can be in region R Exclusion(R1,R2) … occupancy of region R1 and R2 should be mutually exclusive Resource(R1, R2, n) … region R1 is a producer, region R2 is a consumer of some resource with n initial resource values. Barrier(R1,R2) … the kth thread to enter R1 and the kth thread to enter R2 meet and leave their respective regions together So how do we build on this? First of all, to relieve users from having to write logic formulas, we identified five simple patterns that can be combined to specify almost every synchronization problem that we encountered. Synthesize efficient implementations that enforce invariants and link them automatically to sequential implementations of core system functionality.

Contribution to PCES Goals 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. Invariants enable reuse of synchronization “code” across multiple systems and languages reduced effort Synthesis of “correct” synchronization implementations Eliminate a class of subtle errors  reduced testing effort, increased confidence Verification of properties not guaranteed by construction increased confidence

Contribution to Relevant Military Application Provide synchronization aspects for CDA101 - Common Digital Architecture CDA101 provides a common architecture for networking a wide range of target vehicle electronics Synchronization patterns can be used in existing systems and more importantly for future, more complex, target systems. DoD Target Systems Seaborne Targets: ST 2000 Airborne Targets: BQM-74, MQM-107

Project Tasks/Schedule Key Tasks Initial Optimized Full-scale Evaluation Synch Aspect language 5/01 5/02 11/01 + Aspect code synthesis 5/01 11/01 11/01 + Code weaver 5/01 5/02 5/02 + Verification 11/01 5/02 5/02 + 11/01 5/03 Integration 5/03 Non-synch Aspects 11/01

Technical Progress/Accomplishments Rational Unified Process (RUP) Fine-Grain Synchronization Code Complete Program Synch code generators C/??? and Java Complete Program Actors: Use Cases Classes: Use-Case Realizations Component Code Global invariant pattern Extensions and assessment Global Invariant Specs Coarse-Grain Solution Coarse grain generation: SVC and pattern based Initial ST2000 case-study

Synchronization Patterns Barrier(R_1,R_2) BarrierWithInfoEx(R_1,R_2) Relay(R_1,R_2) Bound(R, n) R n In Out R_1 In_1 Out_1 R_2 In_2 Out_2

Multiple Target Detectors and a Single Firing Battery Use-case realizations B1. Wait until a detector locks on a target B2. Receive information from the detector and fire B3. Release the detector T1. Lock on a target T2. Wait until the battery is available T3. Send information to the battery T4. Wait until released

Multiple Target Detectors and a Single Firing Battery Use-case realizations B1. Wait until a detector locks on a target B2. Receive information from the detector and fire B3. Release the detector T1. Lock on a target T2. Wait until the battery is available T3. Send information to the battery T4. Wait until released

Patterns for Target System R_B3 R_T4 B3 T4 R_B1 R_T2 B1 B2 T3 T2 T1 Communicate BarrierWithInfoEx( R_B1, R_T2) Barrier(R_B1, R_T2) R_F Fire Bound(R_F,1) Relay(R_B3, R_T4)

Next Milestones Generate solutions to a large collection of standard synchronization problems Integrate Bandera to check safety/liveness properties Extend synthesis approach to distributed CAN-based systems including CanKingdom and CDA101 Examine existing CDA101 target code to assess how much of the adhoc synchronization code can be expressed in terms of our patterns Provide translations from patterns to CDA101 Add GUI with UML support to current prototype Extend global invariant approach to include real-time properties

Collaborations Stanford (SVC) MIT (analyses to optimize weaved code) Rockwell-Collins, aJile systems (JEM boards) Honeywell Grammatech, Inc. (slicing techniques) Kvaser, AB (CAN Kingdom = CDA 101/11) Seaborne Targets Engineering Lab (CDA101) National Marine Electronics Association (NMEA)

Technology Transition/Transfer DoD Target Systems Seaborne Targets: ST 2000 Airborne Targets: BQM-74 MQM-107 Ground Targets Commercial Applications NMEA 2000, CanKingdom - standards for real-time networking Variable-rate farming, in-vehicle electronics, industrial automation (PLC networks)

Seaborne Target 2000 (ST 2000)

Program Issues Difficult to do long range planning when there is a sense that funding is in jeapordy Program meetings provide little time for technical interchange Involvement of more industrial participants to provide challenge problems Limited equipment availability restricts full deployment of prototypes