1. © 2005 ECNU SEIPrinciples of Embedded Computing System Design1 System design techniques zDesign methodologies. zRequirements and specification.

2. © 2005 ECNU SEIPrinciples of Embedded Computing System Design2 Design methodologies (P.318) zProcess for creating a system. zMany systems are complex: ylarge specifications; ymultiple designers; yinterface to manufacturing. zProper processes improve: yquality; ycost of design and manufacture.

3. © 2005 ECNU SEIPrinciples of Embedded Computing System Design3 Product metrics zTime-to-market: ybeat competitors to market; ymeet marketing window (back-to-school). zDesign cost. zManufacturing cost. zQuality.

4. © 2005 ECNU SEIPrinciples of Embedded Computing System Design4 Mars Climate Observer zLost on Mars in September 1999. zRequirements problem: yRequirements did not specify units. yLockheed Martin used English; JPL wanted metric. zNot caught by manual inspections.

5. © 2005 ECNU SEIPrinciples of Embedded Computing System Design5 Design flow (P.319) zDesign flow: sequence of steps in a design methodology. zMay be partially or fully automated. yUse tools to transform, verify design. ySuch as compiler, CAD. zDesign flow is one component of methodology. Methodology also includes management organization, etc.

6. © 2005 ECNU SEIPrinciples of Embedded Computing System Design6 Waterfall model zEarly model for software development: requirements architecture coding testing maintenance

7. © 2005 ECNU SEIPrinciples of Embedded Computing System Design7 Waterfall model steps zRequirements: determine basic characteristics. zArchitecture: decompose into basic modules. zCoding: implement and integrate. zTesting: exercise and uncover bugs. zMaintenance: deploy, fix bugs, upgrade.

8. © 2005 ECNU SEIPrinciples of Embedded Computing System Design8 Waterfall model critique zOnly local feedback---may need iterations between coding and requirements, for example. zDoesn’t integrate top-down and bottom- up design. zAssumes hardware is given.

9. © 2005 ECNU SEIPrinciples of Embedded Computing System Design9 Spiral model (P.320) requirements design test system feasibility specification prototype initial system enhanced system System life cycle

10. © 2005 ECNU SEIPrinciples of Embedded Computing System Design10 Spiral model critique zSuccessive refinement of system. yStart with mock-ups, move through simple systems to full-scale systems. zProvides bottom-up feedback from previous stages. zWorking through stages may take too much time.

11. © 2005 ECNU SEIPrinciples of Embedded Computing System Design11 Successive refinement model specify architect design build test initial system specify architect design build test refined system

12. © 2005 ECNU SEIPrinciples of Embedded Computing System Design12 Hardware/software design flow requirements and specification architecture hardware design software design integration testing

13. © 2005 ECNU SEIPrinciples of Embedded Computing System Design13 Co-design methodology zMust architect hardware and software together: yprovide sufficient resources; yavoid software bottlenecks. zCan build pieces somewhat independently, but integration is major step. zAlso requires bottom-up feedback.

14. © 2005 ECNU SEIPrinciples of Embedded Computing System Design14 Hierarchical design flow (P.321) zEmbedded systems must be designed across multiple levels of abstraction: ysystem architecture; yhardware and software systems; yhardware and software components. zOften need design flows within design flows.

15. © 2005 ECNU SEIPrinciples of Embedded Computing System Design15 Hierarchical HW/SW flow spec SW architecture detailed design integration test hardware spec architecture HWSW integrate test system spec HW architecture detailed design integration test software

16. © 2005 ECNU SEIPrinciples of Embedded Computing System Design16 Concurrent engineering zLarge projects use many people from multiple disciplines. zWork on several tasks at once to reduce design time. zFeedback between tasks helps improve quality, reduce number of later design problems.

17. © 2005 ECNU SEIPrinciples of Embedded Computing System Design17 Concurrent engineering techniques zCross-functional teams. zConcurrent product realization. zIncremental information sharing. zIntegrated product management. zSupplier involvement. zCustomer focus.

18. © 2005 ECNU SEIPrinciples of Embedded Computing System Design18 AT&T PBX concurrent engineering zBenchmark against competitors. zIdentify breakthrough improvements. zCharacterize current process. zCreate new process. zVerify new process. zImplement. zMeasure and improve.

19. © 2005 ECNU SEIPrinciples of Embedded Computing System Design19 Requirements analysis (P.324) zRequirements: informal description of what customer wants. zSpecification: precise description of what design team should deliver. zRequirements phase links customers with designers.

20. © 2005 ECNU SEIPrinciples of Embedded Computing System Design20 Types of requirements zFunctional: input/output relationships. zNon-functional: ytiming; ypower consumption; ymanufacturing cost; yphysical size; ytime-to-market; yreliability.

21. © 2005 ECNU SEIPrinciples of Embedded Computing System Design21 Good requirements zCorrect. zUnambiguous. zComplete. zVerifiable: is each requirement satisfied in the final system? zConsistent: requirements do not contradict each other.

22. © 2005 ECNU SEIPrinciples of Embedded Computing System Design22 Good requirements, cont’d. zModifiable: can update requirements easily. zTraceable: yknow why each requirement exists; ygo from source documents to requirements; ygo from requirement to implementation; yback from implementation to requirement.

23. © 2005 ECNU SEIPrinciples of Embedded Computing System Design23 Setting requirements zCustomer interviews. zComparison with competitors. zSales feedback. zMock-ups, prototypes. zNext-bench syndrome (HP): design a product for someone like you.

24. © 2005 ECNU SEIPrinciples of Embedded Computing System Design24 Specifications (P.325) zCapture functional and non-functional properties: yverify correctness of spec; ycompare spec to implementation. zMany specification styles: ycontrol-oriented vs. data-oriented; ytextual vs. graphical. zUML is one specification/design language.

25. © 2005 ECNU SEIPrinciples of Embedded Computing System Design25 SDL zUsed in telecommunications protocol design. zEvent-oriented state machine model. telephone on-hook dial tone caller goes off-hook caller gets dial tone

26. © 2005 ECNU SEIPrinciples of Embedded Computing System Design26 Statecharts zAncestor of UML state diagrams. zProvided composite states: yOR states; yAND states. zComposite states reduce the size of the state transition graph.

27. © 2005 ECNU SEIPrinciples of Embedded Computing System Design27 Statechart OR state S1 S2 S3 S4 i1 i2 traditional S1 S2 S3 S4 i1 i2 OR state s123

28. © 2005 ECNU SEIPrinciples of Embedded Computing System Design28 Statechart AND state S1-3S1-4 S2-3S2-4 S5 traditional c d b a r d c b a S1S3 S2S4 S5 AND state b a r b a sab

29. © 2005 ECNU SEIPrinciples of Embedded Computing System Design29 AND-OR tables (P.327) zAlternate way of specifying complex conditions: cond1 or (cond2 and !cond3) cond1T- cond2-T cond3-F AND OR

30. © 2005 ECNU SEIPrinciples of Embedded Computing System Design30 TCAS II specification zTCAS II: aircraft collision avoidance system. zMonitors aircraft and air traffic info. zProvides audio warnings and directives to avoid collisions. zLeveson et al used RMSL language to capture the TCAS specification.

31. © 2005 ECNU SEIPrinciples of Embedded Computing System Design31 RMSL (P.328) zState description:z Transition bus for transitions between many states: state1 inputs state description outputs a b c d transition bus

32. © 2005 ECNU SEIPrinciples of Embedded Computing System Design32 TCAS top-level description CAS power-off power-on Inputs: TCAS-operational-status {operational,not-operational} fully-operational C standby own-aircraft other-aircraft i:[1..30] mode-s-ground-station i:[1..15]

33. © 2005 ECNU SEIPrinciples of Embedded Computing System Design33 Own-Aircraft AND state CAS Inputs: own-alt-radio: integer standby-discrete-input: {true,false} own-alt-barometric:integer, etc. Effective-SLAlt-SLAlt-layer Climb-inibitDescend-inibit Increase-climb-inibit Increase-Descend-inibit Advisory-Status... 1 2 7 1 2 7 Outputs: sound-aural-alarm: {true,false} aural-alarm-inhibit: {true, false} combined-control-out: enumerated, etc.

34. © 2005 ECNU SEIPrinciples of Embedded Computing System Design34 CRC cards (P.330) zWell-known method for analyzing a system and developing an architecture. zCRC: yClasses; yResponsibilities of each class; yCollaborators are other classes that work with a class. zTeam-oriented methodology.

35. © 2005 ECNU SEIPrinciples of Embedded Computing System Design35 CRC card format Class name: Superclasses: Subclasses: Responsibilities:Collaborators: Class name: Class’s function: Attributes: frontback

36. © 2005 ECNU SEIPrinciples of Embedded Computing System Design36 CRC methodology (P.331) zDevelop an initial list of classes. ySimple description is OK. yTeam members should discuss their choices. zWrite initial responsibilities/collaborators. yHelps to define the classes. zCreate some usage scenarios. yMajor uses of system and classes.

37. © 2005 ECNU SEIPrinciples of Embedded Computing System Design37 CRC methodology, cont’d. zWalk through scenarios. ySee what works and doesn’t work. zRefine the classes, responsibilities, and collaborators. zAdd class relatoinships: ysuperclass, subclass.

38. © 2005 ECNU SEIPrinciples of Embedded Computing System Design38 CRC cards for elevator (P.331) zReal-world classes: yelevator car, passenger, floor control, car control, car sensor. zArchitectural classes: car state, floor control reader, car control reader, car control sender, scheduler.

39. © 2005 ECNU SEIPrinciples of Embedded Computing System Design39 Elevator responsibilities and collaborators