of 17/17
Automatic Derivation, Integration, Automatic Derivation, Integration, and Verification of and Verification of Synchronization Aspects in Object- Synchronization Aspects in Object- Oriented Design Methods Oriented Design Methods DARPA Order K203/AFRL Contract F33615-00- C-3044 rincipal 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

Principal Investigators

  • View
    41

  • Download
    0

Embed Size (px)

DESCRIPTION

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. - PowerPoint PPT Presentation

Text of Principal Investigators

  • Automatic Derivation, Integration, and Verification of Synchronization Aspects in Object-Oriented Design Methods

    DARPA Order K203/AFRL Contract F33615-00-C-3044

    Principal InvestigatorsMatt DwyerJohn HatcliffMasaaki MizunoMitch NeilsenGurdip SinghDepartment of Computing and Information Sciences

    Kansas State Universityhttp://www.cis.ksu.edu/santos

  • Problem DescriptionEmbedded systems are growing in complexity and developers are looking towards OO technologies to manage that complexityDesign methods for OO do not treat synchronization effectivelyEmbedded systems software is multi-threaded for performance reasonsSystem correctness relies on correct synchronization of multiple activitiesSynchronization design/implementation is low-level and platform specific Error prone and not reusable

  • Project Objectives

  • Technical Approach/AccomplishmentsCompleteProgramPrototype release 9/01

  • Technical Approach --- SpecificationsUsers never write raw invariants but instead build synchronization specifications using a collection of global invariant patterns (idioms)Bound(R,n) at most n threads can be in region RExclusion(R1,R2) occupancy of region R1 and R2 should be mutually exclusiveResource(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

  • Contribution to PCES GoalsInvariant patterns enable reuse of synchronization solutions across multiple systems and languagesEvaluate reduction in effort in the context of OEPson existing applications, if suitable code/design history is availableon 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 effortas aboveThe 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 ApplicationApply our approach to CDA 101 based systemsCDA 101 provides a common architecture for networking target vehicle electronics using CANExtract synchronization regions from existing applications and re-engineer using our approachDoD Target System StudiesSeaborne (ST 2000) and Airborne (BQM-74, MQM-107)CDA 101 and NMEA 2000 co-evolving standardsNMEA 2000 working group memberRegular interaction with and source-code from Seaborne Targets Engineering Group (NAWC Point Mugu, CA)

  • Project Tasks/ScheduleIntegrationVerificationCode weaverAspect code synthesisSynch Aspect languageKey TasksNon-synch AspectsInitialOptimizedFull-scaleEvaluation5/015/015/015/0211/0111/0111/0111/01 +5/025/025/0211/01 +5/02 +5/035/02 +5/03

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

  • Technology Transition/TransferCDA 101 based Target SystemsSeaborne Targets: ST 2000Airborne Targets:BQM-74MQM-107Commercial ApplicationsNMEA 2000, CanKingdom - standards for real-time networkingPrecision farming, industrial automation

  • Program IssuesDifficult to do long range planning when there is a sense that funding is in jeopardyProgram meetings provide little time for technical interchangei.e., identifying future collaboratorsInvolvement of more industrial participants to provide challenge problemsi.e., need more than code and documentationLimited equipment availability restricts full deployment of prototypes

  • Synchronization RegionsSystem

  • Synchronization Patterns (excerpts)Bound(R, n)Barrier(R_1,R_2) BarrierWithInfoEx(R_1,R_2) 8 basic patterns in current collection (many more composite patterns) Pattern compositions can solve all synchronization problems in Andrews and Hartleys books We welcome challenge problems from PCES participants

  • Multiple Target Detectorsand a Single Firing Battery

    Use-case realizations B1. Wait until a detector locks on a targetB2. Receive information from the detector and fire B3. Release the detectorT1. Lock on a targetT2. Wait until the battery is availableT3. Send information to the batteryT4. Wait until released

  • Multiple Target Detectorsand a Single Firing Battery

    Use-case realizations B1. Wait until a detector locks on a targetB2. Receive information from the detector and fire B3. Release the detectorT1. Lock on a targetT2. Wait until the battery is availableT3. Send information to the batteryT4. Wait until released

  • Patterns for Target System

  • Next Milestones (6-9-12 months)Extend synthesis approach to distributed CAN-based systems including CanKingdom and CDA 101Public distribution of prototype synchronization specification, code generation, and weaving tools

    Generate solutions to other synchronization problems from CDA 101, Industrial Automation (KTEC) and Agricultural (John Deere) applicationsExtend global invariant approach to address real-time synchronization properties (e.g., priority inversion)Integrate Bandera to check safety/liveness properties

  • Funding Profile and Financial Expenditures to DateWe 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 1st funding period was shifted to the second period. This means that 100% burn of the second periods 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.

  • Technical Approach --- Tool Architecture

  • Seaborne Target 2000 (ST 2000)

    This morning Im going to brief you on the PCES project at Kansas State

    Ill give the first part of the briefing and Masaaki Mizuno will conclude

    John Hatcliff and Mitch Neilsen are both at the meeting so if youHave specific technical questions that I dont cover feel free to talk to any ofUs.The trajectory for embedded systems is one of increasing complexitymore aggressive missionsmore autonomy and capability requiredmore reliability and performance required

    To manage complexity, developers are looking for solutions that have been effective in non-embedded domains

    One hallmark of embedded software is concurrency and proper synchronization of dependent sub-calculations in such a system is crucial to correct operation

    Here are the goals of the project in a bit more detailWe 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 (weve 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.From the initial specification, well 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.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.Finally, well be evaluating this approach using some military systems for networking target vehicles.

    First: identify boundary and entity (persistent data structures) classes

    Second: develop use case realizations using initial classes, add control classes as necessary (to order the operations on the boundary and entity classes)

    Third: identify use cases at system interface

    Our extensions involve identifying the dependent parts of different systemComponents that must be synchronized: those parts are called regions

    We have a prototype version of this process operating with an extensiveCollection of invariant idioms identified and implementations of coarseAnd fine grain generation tools implemented for multiple platforms.

    The underlying logic used to express synchronization policies as global Invariants is expressive, but hard to use.

    to relieve users from having to write logic formulas for invariants, we identified commonly occuring idioms or specification patterns that can be combined to specify almost every synchronization problem that we encountered.

    Tools then automatically translate a composite specification to an implementation.

    2 main goals of PCES

    Reduce effort via reuse across systems across platforms, e.g., porting of a system

    Increase confidence & reduce effort via correct by construction Both of these require evaluation on realistic systems two approaches: examine existing system design artifacts conduct controlled studies on student class projectsFocus on the domain of CDA systems reengineer existing systems and assess impact

    We have access to several systems and are working to aquire more

    Contacts with CDA 101 developed out of joint work on standards bodies David Purdy from Naval Air Warfare Center at Point Mugu, CA Mitch Neilsen of our team are both involved in the National Marine Electronics Association marine vehicle networking standards group

    This has led to regular interaction between our team and the group at Point Mugu and an exchange of artifacts.

    We hope to leverage this as they move towards the development of more sophisticated target systems, e.g., with distributed control and redundancyWe currently have initial versions of our aspect language for synchronization, a synchronization code synthesis toolset and a simple code weaver.

    We have much more to do before we can do any significant evaluation of our approach, but we plan to pursue the development of the tool components and evaluation of the approach on examples simultanously this summer and fall.We believe the early feedback from applying our approach will be valuable.

    We are working to develop a significantly more robust tool support for specifying code regions and the synchronization policies that govern their execution over the next year. We will also be exploring extensions to the existing synchronization aspects and integration of our verification technologies.

    Our ultimate goal is to integrate our approach into a publicly available development environment like Argo/UML by the end of the project.Finally, the other extensions are to incorporate the method into RUP and to check safety/liveness properties using our existing software model-checking tools. In the end, when you put all of this together, the first iteration of our tools should have the following architecture.