1. 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

2. 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

3. 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

4. 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.

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 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

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

13. 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

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

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

16. Seaborne Target 2000 (ST 2000)

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