Model Driven Engineering

1. Model Driven Engineering Bill Chown – Mentor Graphics

2. What is Model-Driven Development? • There are many terms used with Model… • Key characteristics of Model Driven Development (MDD) • The model is the design • The model will grow, evolveand extend • There is a flow from abstraction to abstraction • Implementation is directly derivedfrom the model Model DrivenEngineering Model Based … Model Driven Development BC, Inside xtUML 1, October 2012

3. System Design Challenges • Design requirements are becoming more complex • Lower cost, lower power, lower weight • Increased performance, reliability, or safety • Convergence of multiple disciplines • Everything has to work together: Digital, Analog, Software, Mechanical, etc. • Multi-company, distributed supply chains • Complicated communication via a number of domain-specific file formats, tools, and protocols • Design optimization • More than just getting a design to ship, a successful project relies on predictable schedules, and optimization of Reliability, Performance, Manufacturing Cost, and Life-cycle Cost BC, Inside xtUML 1, October 2012

4. Attributes of Embedded Systems • Domain-specific • Highly heterogeneous • Distributed over networks • Highly interactive with physical world • Require multiple disciplines to implement • Validated mainly through physical prototyping • System integration and test organizations are pivotal • Subject to rigorous quality, certification, qualification rules BC, Inside xtUML 1, October 2012

5. A B C users – the design team has many roles • A: Architect or Systems Engineer • Needs flexibility, tradeoffs • Requirements modeling, system architecture choices • active requirements validation as an Executable Specification • B: Component Designer, hardware or software • Discipline-specific factors become the focus • Narrower domain, not directly controlled by other domains • Representative execution environment for design and debug • efficient implementation pathway to hardware and/or software • C: System Integrator • Multi-domain connections, communications • Real world timing, behavior, interactions • Powerful virtual platforms address both hardware and software BC, Inside xtUML 1, October 2012

6. The Key System Design Questions • Am I building the right thing? • Validating the design against the specification • Optimizing design goals and performance • System Level Design and Validation • Am I building it correctly? • Verifying no functional errors in design blocks • And that reused blocks are integrated properly • Implementation-Based Platform Verification • Am I considering the right costs? • Lifecycle costs • Supply chain interactions • Cost of change BC, Inside xtUML 1, October 2012

7. Concept to Solution – exploring the space Requirements Requirements ConceptModel • Initial ideas are often no more than conceptual proposals • A Concept model allows exploration of the problem or need • From a “Concept” model to [a set of] potential solutions • Explore and define requirements • Propose solution architectures and content • Demonstrate and exchange ideas with stakeholders • Consider and trade-off needs and costs • Create development-oriented derived requirements • Actionable, concrete, executable, traceable & implementable Looking at the Problem Internal-external “thought” exchange SolutionModels Looking at Performance BC, Inside xtUML 1, October 2012

8. Development of the model(s) Requirements ConceptModel Requirements INTEGRATION │ VALIDATION │ VERIFICATION DEMONSTRATION Looking at the Problem SolutionModels Internal-external “thought” exchange Looking at Performance Domain Engineers SystemModel Elaboration from Solution Models based on system performance Iteration Integrated Team ArchitecturalModel SubsystemModels ImplementationModel TargetModel BC, Inside xtUML 1, October 2012

9. Demonstrate – with an Executable Specification Requirements • Deliver on the two key topics • Show what we have • Enable initial questions to be asked • Lead on to a successful design • Build an effective design process • Can be reused time and again on the path to implementation • Create a demonstration of the requirements, in an active form, that can be assessed and adjusted ExecutableSpecification Why? What? ? ? ? Derived ? How? Evolve the Model Derive further Requirements BC, Inside xtUML 1, October 2012

10. Drive Implementation Concept ExecutableSpecification ExecutableSpecification SoftwareDevelopment HardwareDevelopment Tests Tests Software Hardware BC, Inside xtUML 1, October 2012

11. Virtual Platform Concept ExecutableSpecification SoftwareDevelopment HardwareDevelopment Tests Virtual Platform HW/ /SWVirtual Platform Software Hardware Tests Software Hardware Software Hardware BC, Inside xtUML 1, October 2012

12. Essential Model Abstractions • Platform Independent Model • Function, architecture, interfaces, interactions • Demonstrate requirements are understood and met • Platform Dependent Models • Hardware architecture, virtual prototypes • Software architecture, partitions, data • Determine resources, performance goals • Hardware-software co-design, before physical implementation • Platform Specific Models • Implementations • Verification • Test • Deliverables BC, Inside xtUML 1, October 2012

13. Implementation • Models can and should drive implementation • In software, models generate code • Ready to run, configured for RTOS, etc. • Now hardware flows are emerging • C to RTL synthesis flows • UML to SystemC for simulation / validation • Test languages also support direct generation The evolution of a MDD model from requirements to prototype and then production BC, Inside xtUML 1, October 2012

14. Best practices in adopting MDD solutions • Consider the full flow context • Start small • Identify a top question to answer earlier in the flow • Contain the application of new flows to a measurable scale • Look for cycle time improvements • Look for data continuity rather than re-entry • Look for early design iterations – not in implementation BC, Inside xtUML 1, October 2012

15. xtUML.org The Open Source Initiative for xtUML BC, Inside xtUML 1, October 2012