1 / 32

Model-Based Agility for Embedded Systems Development

Dr. Bruce Powel Douglass, Ph.D. Chief Evangelist, IBM Rational Bruce.Douglass@us.ibm.com Twitter: @BruceDouglass Yahoo: http://tech.groups.yahoo.com/group/RT-UML IBM: www-01.ibm.com/software/rational/leadership/thought/brucedouglass.html. Model-Based Agility for Embedded Systems Development.

skarl
Download Presentation

Model-Based Agility for Embedded Systems Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Dr. Bruce Powel Douglass, Ph.D. Chief Evangelist, IBM Rational Bruce.Douglass@us.ibm.com Twitter: @BruceDouglass Yahoo: http://tech.groups.yahoo.com/group/RT-UML IBM: www-01.ibm.com/software/rational/leadership/thought/brucedouglass.html Model-Based Agility for Embedded Systems Development

  2. Agenda • State of Agile in the Systems Space • High-Fidelity Modeling • Model-Based Testing • Dependable by Design …. With Agile • Does it Work? Case Studies • New Technologies and Approaches in the 21st Century

  3. Typical agile project The State of Agile in the Systems Space IBM Agility@Scale™

  4. Agile Processes Arch & Test Driven, Reuse Collaborative platforms Iterative processes Middleware components Mature commercial tools Waterfall Governance Stovepipe architectures Proprietary tools/methods Timeto value Timeto value Timeto value The Agile Time to Value Curve 100% Build Progress Project Delivery Time

  5. Addressing misconceptions about agile • Agile teams write documentation • Agile teams model • Agile requires greater discipline than traditional approaches • Agile teams do more planning than traditional teams, but it’s dynamic not ballistic • Agile is more predictable than traditional • Agile scales very well • Agile is not a fad, it is being adopted by the majority of organizations • Agile can do fixed price, but there’s more effective options available to you • Agile processes can be certified to whatever CMMI level you desire • Agile methods can be used in the system space for both systems engineering and embedded sw • Agile can be used to develop high security/reliability/safety systems

  6. Embedded Agile: The Harmony™ Process

  7. Harmony™ for Embedded RealTime Agile Practices Use dynamic 2-level planning Incrementally construct/unit test several times per day (nanocycle) Incremental development (microcycle) High-Fidelity Modeling Continuous integration Dependability analysis/assessment in parallel with development Avoid defects with defensive development Apply design patterns Intelligently Actively manage project risks Use model-code associativity to automatically maintain model-code in sync Practices are workflows that produce andconsume work products to achieve the goals based on principles and concepts

  8. Use Dynamic Planning • A schedule is always developed with incomplete information • There are things you don’t know • Some of the things you know are wrong or will change • Harmony recommends a two-tier planning approach • Overall schedule plans the set of iterations and their expected content • Each iteration has a more detailed plan whose scope is a single iteration • This is done at the start of each iteration • At the end of each iteration, the current project status is used to update the overall plan Project plan Microcycle1 Microcycle 2 Microcycle 3 plan Microcycle 4 update Iteration plans

  9. Nanocycle ContinuousIntegration Incremental High-Fidelity Modeling Test Driven Development Unit testing Typically 10-30minutes Embedded Agile SW Development

  10. High-fidelity model-based engineering (Hi-MBE) Incremental functional analysis with use cases Executable requirements modeling with SysML/UML Test-driven development of system specifications Integrated safety and reliability analysis Model-based handoff to downstream engineering Automated document generation from model artifacts Best Practices for Modern Systems Engineering SystemsEngineering 10

  11. Agile High-Fidelity Modeling

  12. UMMI – UML Maturity Model Index

  13. Mechanical Specification Functional Model Subsystems, interfaces, Subsystem use cases/ Requirements Model and text ArchitecturalModel Model-basedhandoff Executable use casesFunctional and QoS requirements SubsystemModel(s) ElectronicSpecification Trade-off analysis DependabilityModel Model and text ControlModel Safety, reliability, and security analysisFTA, FMEA, FEMCA,Asset Diagram, SAD SoftwareSpecification Control algorithms,mathematical models Model and text Models and Viewpoints in Model-Based Systems Engineering

  14. Model-Based Handoff to Downstream Engineering

  15. Model-Based Testing

  16. Where Testing fits into the Development Process Harmony/ESW Microcycle (Spiral) Repeats every 4-6 weeks Harmony for Embedded RealTime™

  17. TDD – Requirements Based Testing • Uses “Requirements” sequence diagrams to drive the execution and validation of the system

  18. Continuous Testing in Harmony™ for Embedded RealTime Final acceptance testing at end of project and at key delivery points Design and requirements testing every incremental prototype every 4-6 weeks Software and system integration performed daily or weekly Continuous informal and formal testing via elaboration and execution every few minutes

  19. Dependable by Design … with Agile

  20. Dependable by Design … with Agile • Dependability has three aspects • Safety • Reliability • Security • All three cross-cutting concerns must be addressed • Safety and reliability are well established disciplines within the systems space, but … • There is no presence today of requirements and design concepts or tools within the confines of industrial control systems for cybersecurity let alone SoS that incorporate many control systems. These have critical impacts on safety and reliability • Activities must address these concerns at • Requirements • Systems engineering • Software development • It is crucial that we provide tools and methods for reasoning about these concerns at the requirements and design level Ref: Protecting Industrial Control Systems from Electronic Threats by Joe Weiss

  21. Model-Based Dependability Analysis with FTA

  22. Linking Dependability Analysis to Reqs and Model Elements

  23. Security Analysis Diagram • Security Analysis Diagram (SAD) is like a Fault Tree Analysis (FTA) but for security, rather than safety • It looks for the logical relation between assets, vulnerabilities, attacks, and security violations • Permits reasoning about security • What kind? • How much? • Risk assessments

  24. Asset Diagram • An Asset Diagram looks at the semantic relations between roles, authentication, vulnerabilities, and countermeasures. It is a way of representing the security-relevant design elements. • Here it is shown with traceability links to requirements • Assets can be • Physical • Informational • Currency • Resource • Security

  25. Auto-generation of Dependency-Relevant Summary Data Fault Source Matrix, Fault Detection Matrix, Fault-Requirement Matrix, Hazard Analysis… • Traceability improves your ability to make your safety/security case • Dependability metadata guides downstream engineering work

  26. Harmony/SE: Design Synthesis

  27. Does it Work? Case Studies

  28. Eaton and UPS The Solution The Challenge Developed the hybrid drive train systems engineering model with a combination of high-fidelity modeling and agile methods. • Create series hydraulic hybrid vehicle that can achieve 60-70% fuel emission reduction for challenging UPS drive cycle for the vehicle - Instructed team in the use of Rhapsody and DOORS - Multiple workshops solidified the system requirements and identify many missing requirements - Using the Rhapsody safety analysis profile, the engineers performed a detailed safety analysis and with trace links to the system architecture and requirements - System engineering model handed off to software and electronics and mechanical eeers for development Results/Accomplishments - Significantly reduced requirements defects before software, electronics, and mechanical engineers got to work - Accelerated progress on the most complex hybrid design by Eaton and perhaps in the world - System successfully achieved its aggressive fuel economy goals (70% improvement) and achieved 40% reduction in CO2 emissions - Successfully used modeling for both systems engineering and for software development - Used automatic code generation for vehicle software reducing defects and improving time-to-market

  29. Ikerlan-IK4 The Solution The Challenge Developed wind turbine models for system and software development using product line engineering tooling to save time to market for product lines • Design and build wind turbines that automatically optimize their performance based on environmental factors • - Adopted Rational Rhapsody and agile model-driven development to model their system architecture • - Use of UML to visual the architecture, couple with SysML allowed them to formulate an overall architecture approach Results/Accomplishments • 90% reduction in development time for each customized wind turbine model • 25% reduction in cost of development for wind turbine control systems • Reduced development time by a factor of 10 for each variation in its product line

  30. Where do we go from Here?

  31. Technological Advances for SW Development • Autonomic Computing (AC) systems • Refers to self-governing massively parallel computing inspired by biological computing • Adds agent-oriented goal-directed elements • An agent is an autonomous element that embeds policies that achieves goals specified by rules or minimization of energy functions • Collective Intelligence (COIN) • Related to, but distinct from AC • Attempts to create desired system properties (including QoS) as a set of emergent properties from independent autonomous agents in the same way ant colonies display emergent intelligent behavior • Main obstacle is the selection of local energy functions that produce the desired emergent behavior • Run-time interface adherence • Specification of interfaces with run-time middleware ensuring • Preconditions • Postconditions • Class invariants • See Babel home page as an example of such an IDL https://computation.llnl.gov/casc/components/#page=home

  32. References

More Related