Embedded Design

622 views

Published on

The big-bang model
The code-and-fix model
The waterfall model
The spiral model

Published in: Engineering
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
622
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Embedded Design

  1. 1. Embedded Systems Design By AJAL.A.J ASSISTANT PROFESSOR Electronics & Communication Engineering 1 Dept
  2. 2. Name of University - Class Title What Is An Embedded System ?  A type of computer system.  Some of the Most Common Traditional Definitions : – Embedded systems are more limited in hardware and/or software functionality then the PC. – An embedded system is designed to perform a dedicated function – …  Why don’t these definitions entirely apply, today?
  3. 3. Name of University - Class Title What is an Embedded System [Continued] ?  Automotive – i.e. : Ignition Systems, Engine Control, Antilock Braking System, …  Consumer Electronics – i.e. : TVs, STBs, appliances, toys, automobiles, cell phones …  Industrial Control – i.e. : robotics, control systems…  Medical – i.e. : Infusion Pumps, Dialysis Machines, Prosthetic Devices,Cardiac Monitors, …  Networking – i.e. : routers, hubs, gateways, …  Office Automation – i.e. : fax machines, photocopiers, printers, monitors, … ** Aside from being types of computer systems, there is no single definition or characterization of embedded systems reflecting them all. **
  4. 4. Systems engineering point of view: • When approaching embedded systems architecture design from a systems engineering point of view, several models can be applied to describe the cycle of embedded system design. • Most of these models are based upon one or some combination of the following four development models:
  5. 5. System Engineering Life Cycle Models four development models:
  6. 6. four development models: 1.The big-bang model 2.The code-and-fix model 3.The waterfall model 4.The spiral model
  7. 7. big-bang model • The big-bang model, in which there is essentially no planning or processes in place before and during the development of a system. Ad HOC MODEL
  8. 8. Name of University - Class Title Big-Bang Model  Developer receives problem statement.  Developer works in isolation for some extended time period.  Developer delivers result.  Developer hopes client is satisfied.
  9. 9. code-and-fix model The code-and-fix model, in which product requirements are defined But no formal processes are in place before the start of development.
  10. 10. waterfall model The waterfall model, in which there is a process for developing a system in steps, where results of one step flow into the next step.
  11. 11. Waterfall Model with Back Flow (sometimes this is implied by “waterfall”) Requirements Design Implementation Test Adjustments made to immediately previous phase based on issues with successive phase. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  12. 12. Why Not Waterfall? 1. Complete Requirements Not Known at Project Start 60 50 40 30 20 10 0 10 100 1000 10000 100000 Project Size in Function Points Creeping Req's as % of Orig These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt Source: Applied Software Measurement, Capers Jones, 1997. Based on 6,700 systems.
  13. 13. Function Point?  A function point is a unit of complexity used in software cost estimation. Function points are based on number of user interactions, files to be read/written, etc. SLOC means number of source lines of code, also a measure of program complexity. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  14. 14. Why Not Waterfall? 2. Requirements are not stable/unchanging.  The market changes—constantly.  The goals of the stakeholders change. Source: Craig Larman  The technology changes. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  15. 15. Why Not Waterfall? 3. The design may need to change during implementation.  Too many variables, unknowns, and novelties.  A complete specification must be as detailed as code itself.  Discover Magazine, 1999: Software characterized as the most Source: Craig Larman  Requirements are incomplete and changing.  Software is very “hard”. complex “machine” humankind builds. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  16. 16. spiral model The spiral model, in which there is a process for developing a system in steps, and throughout the various steps, feedback is obtained and incorporated back into the process.
  17. 17. “Life-Cycle” Models ….  Iterative Models  Spiral Model & Variants  ROPES Model  Controlled Iteration Model: Unified Process  Time Box Model  Scrum Model  Fountain Model These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  18. 18. Boehm Spiral Model (of which some other models are variants)  An iterative model developed by Barry Boehm at TRW (1988), now Prof. at USC  Iterates cycles of these project phases: 1 Requirements definition 2 Risk analysis 3 Prototyping 4 Simulate, benchmark 5 Design, implement, test 6 Plan next cycle (if any) These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt Prof. Barry Boehm
  19. 19. Boehm Spiral Model These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  20. 20. Risk? What risk?  One major area of risk is that the scope and difficulty of the task is not well understood at the outset.  This is the so-called “wicked problem” phenomenon. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  21. 21. “Wicked Problems”  Many software development projects have been characterized as “wicked problems”, meaning: “problems that are fully understood only after they are solved the first time” (however poorly)  Does not apply only to software These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  22. 22. Source of some of this Prentice-Hall, 1990 basically a criticism of the waterfall model “wicked” term first used in H. Rittel and M. Webber, Dilemmas in a general theory of planning, Policy Sciences, 4, pp. 155-169, Elsevier, 1973. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  23. 23. Some Roots of Wickedness  Risk: A customer not knowing exactly what he/she wants; changing expectations as project progresses.  Risk: Staff who are inexperienced in the problem domain, or with the appropriate implementation techniques. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  24. 24. The Waffle Principle  “Plan to throw the first one away; you will anyhow.” Fred Brooks, “The Mythical Man-Month: Essays on Software Engineering”, Addison Wesley, 1975. Revised in 1995.  another indication that building a large software system is wicked These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  25. 25. Wicked Problems  The presence of wickedness is what makes the iterative / incremental approaches most appealing.  Methodologies and organizational techniques can help control the degree of wickedness. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  26. 26. US Air Force Risk Classification  Performance risk: The project might not meet requirements or otherwise be fit for use.  Cost risk: The budget might get overrun.  Support risk: The software might not be adaptable, maintainable, extendable  Schedule risk: The project might be delivered too late. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  27. 27. Ways to Manage Risk  Risk cannot be eliminated; it must be managed.  Do thorough requirements analysis before the design.  Use tools to track requirements, responsibilities, implementations, etc.  Build small prototypes to test and demonstrate concepts and assess the approach, prior to building full product.  Prototype integration as well as components. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  28. 28. Front-Loading  Tackle the unknown and harder parts earlier rather than later.  Better to find out about infeasible, intractable, or very hard problems early.  The easy parts will be worthless if the hard parts are impossible.  Find out about design flaws early rather than upon completion of a major phase. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  29. 29. ROPES Model - Similar to Spiral Rapid Object-Oriented Process for Embedded Systems Bruce Douglass  Iterates the following sequence of phases repeatedly:  Requirements analysis  System analysis  Object analysis  Architectural design  Design  Mechanistic design  Detailed design  Coding  Unit testing  Integration testing  Validation testing  Iterative prototypes http://www.sdmagazine.com/breakrm/features/s999f1.shtml These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  30. 30. ROPES Model Rapid Object-Oriented Process for Embedded Systems Bruce Douglass These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  31. 31. Controlled-Iteration Model  Four phases per major cycle  Inception: Negotiate and define product for this iteration  Elaboration: Design  Construction: Create fully functional product  Transition: Deliver product of phase as specified  The next phase is started before the end of the previous phase (say at 80% point). These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  32. 32. Rational Unified Process (a form of controlled iteration) Process Workflows Business Modeling Requirements Analysis & Design Implementation Test Supporting Workflows Management Environment Preliminary Iteration(s) Iter. #1 Phases Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iterations within phases These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt Iter. #m+1 Deployment Configuration Mgmt Inception Elaboration Construction Transition
  33. 33. Time-Box Requirement (can be used in iterative or incremental)  Requirements analysis  Initial design  while( not done ) { Develop a version within a bounded time Deliver to customer Get feedback Plan next version } These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  34. 34. Scrum, A cure for the Wicked? Scrum first mentioned in “The New New Product Development Game” (Harvard Business Review 86116:137-146, 1986) These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  35. 35. Scrum Model (incremental model, includes some aspects of team structure, as well as process) Start A small group is responsible for picking up the ball and moving it toward the goal. See http://www.cetus-links.org/oo_ooa_ood_methods.html These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt Goal
  36. 36. Argument for the Scrum Model over other iterative models  A software development project might not be compartmentalizable into nice clean phases as the Spiral models suggest.  Scrum may be “just the thing” for wicked problems, because the team can quickly react to new information. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  37. 37. Some Principles of Scrum Model  Always have a product that you can theoretically ship: “done” can be declared at any time.  Build early, build often.  Continuously test the product as you build it.  Assume requirements may change; Have ablility to adapt to marketplace changes during development.  Small teams work in parallel to maximize communication and minimize overhead. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  38. 38. Concepts Used in Scrum (from http://www.controlchaos.com/ap.htm)  Backlog - an identification of all requirements that should be fulfilled in the completed product. Backlog items are prioritized.  Objects/Components - self-contained reusable modules  Packets - a group of objects within which a backlog item will be implemented. Coupling between the objects within a packet is high. Coupling between packets is low.  Team - a group of 6 or fewer members that works on a packet.  Problem - what must be solved by a team member to implement a backlog item within an object(s) (includes removing errors)  Issues - Concerns that must be resolved prior to a backlog item being assigned to a packet or a problem being solved by a change to a packet  Solution - the resolution of an issue or problem  Changes - the activities that are performed to resolve a problem  Risks - the risk associated with a problem, issue, or backlog item These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  39. 39. Use of Iteration in Scrum http://www.controlchaos.com/scrumwp.htm  Each iteration consists of all of the standard Waterfall phases,  but each iteration only addresses one set of functionality.  Overall project deliverable has been partitioned into prioritized subsystems, each with clean interfaces.  Test the feasibility of subsystems and technology in the initial iterations.  Further iterations can add resources to the project while ramping up the speed of delivery.  Underlying development processes are still defined and linear. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  40. 40. Fountain Model (Ian Graham, et al., The OPEN Process Specification OPEN = Object-oriented Process Environment and Notation ) These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  41. 41. Additional Models/Acronyms  RAD (Rapid Application Development): time-boxed, iterative prototyping  JAD (Joint Application Development): Focus on developing models shared between users and developers.  See http://faculty.babson.edu/osborn/cims/rad.htm for additional points. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  42. 42. Extreme Programming (XP) (cf. http://www.extremeprogramming.org/rules.html)  User stories (something like use cases) are written by the customer.  Complex stories are broken down into simpler ones (like a WBS).  Stories are used to estimate the required amount of work.  Stories are used to create acceptance tests.  A release plan is devised that determines which stories will be available in which release.  Don’t hesitate to change what doesn’t work. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  43. 43. Extreme Programming (XP)  Each release is preceded by a release planning meeting.  Each day begins with a stand-up meeting to share problems and concerns.  CRC cards are used for design. [XP and CRC were created by the same person, Kent Beck.]  Spike solutions are done to assess risks.  The customer is always available. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  44. 44. Extreme Programming (XP)  All code must pass unit tests, which are coded before the code being tested (test-driven design).  Refactoring is done constantly.  Integration is done by one pair.  Integration is done frequently.  Optimization is done last.  Acceptance tests are run often. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  45. 45. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  46. 46. System Metaphor? “Choose a system metaphor to keep the team on the same page by naming classes and methods consistently. What you name your objects is very important for understanding the overall design of the system and code reuse as well. Being able to guess at what something might be named if it already existed and being right is a real time saver. Choose a system of names for your objects that everyone can relate to without specific, hard to earn knowledge about the system. For example the Chrysler payroll system was built as a production line. At another auto manufacturer car sales were structured as a bill of materials. There is also a metaphor known as the naive metaphor which is based on your domain itself. But don't choose the naive metaphor unless it is simple enough.” These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt
  47. 47. Keller’s Roll-Your-Own Software Life-Cycle Construction Kit Requirements Analysis System Design Program Design Implement Integration Test Detailed Design Code Walkthrough Port These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU/Prescott SE300 usage with his kind permission. Slides avaialble online at http://www.cs.hmc.edu/courses/2005/spring/cs121/slides/slides05.ppt Unit Test Acceptance Test Prototype Design Review Requirements Elicitation Requirements Specification Risk Analysis Fix Errors Validate Verify Integrate Cost Analysis Configure Maintain Document Simulate Train Evaluate Party
  48. 48. Embedded Systems Design and Development Lifecycle Model
  49. 49. Lifecycle Model
  50. 50. Life Cycle Model
  51. 51. Embedded System Life Cycle Models (1) 3V Model (2) Multiple V Model
  52. 52. “V” Model Each phase has corresponding test or validation counterpart Requirements Analysis System Design Program Design Implementation Acceptance Integration Test Unit Test Test
  53. 53. 1. 3V model
  54. 54. 3V model
  55. 55. Sawtooth Model (Brugge) Requirements Analysis System Design Program Design Implementation Integration Test Unit Test Acceptance Test Demo Prototype 1 Demo Prototype 2
  56. 56. 2. Multiple v model
  57. 57. Advanced Life Cycle Models (1)MDA (2) Y-Model (3) Platform-Based Design
  58. 58. 1. MDA MODEL MODEL DRIVEN ARCHITECTURE
  59. 59. 2. Y - MODEL
  60. 60. 3. PLATFORM BASED DESIGN MODEL
  61. 61. Approach used in Platform based Model
  62. 62. Embedded design life cycle diagram
  63. 63. Different Stages (stage 1) having a strong technical Foundation (stage 2) understanding the Architectural Business Cycle (stage 3) defining the architectural patterns and models (stage 4) defining the architectural structures (stage 5) documenting the architecture (stage 6) analyzing and reviewing the architecture (stage 7) Maintenance
  64. 64. 7 stages can be merged to 3 steps 1. Product specification 2. Hardware/software partitioning 3. Hardware/software integration
  65. 65. Tools used in the design process
  66. 66. Product specification • R&D engineers want to incorporate everything: – Wastes time and resource • Marketing and sales will usually execute the product specification • Engineers, however, should be involved in some customer tours – CPIF - Cost Plus Incentive-Fee (Contract) – Listening to the customer is good
  67. 67. Common success factors • Design team shares a common vision of the product • Failed projects probably did not share a common vision of project goals – Low cost medium performance versus time to market versus high performance and medium cost • Often overlooked part of the product specification phase - the requirement of the development tools
  68. 68. Common success factors • Embedded systems projects are late to market because engineers do not have access to the best tools – Tools should be part of the product specification – Prevents unrealistic expectations • is/is-not list, or musts and wants
  69. 69. Hardware/software partitioning • Embedded design usually involves hardware and software • Hardware utilizes Micro-processors, Micro-controllers and Digital Signal Processors but are neither used nor perceived as computers. Generally, software is used for features and flexibility, while hardware is used for performance. • What is the partitioning decision? • Different than application developers – Not a good idea to h/w enhance h/w to address part of a problem – The old days of co-processors (FPUs) are over - emulated
  70. 70. Algorithm • Steps required to implement a design • Combination of hardware components and software components • Hardware/software partitioning also involves the hows of partitioning the algorithm (software only, hardware only, combination) • Think about the simple algorithm of Fibonacci series
  71. 71. Embedded design requirements • Price sensitive • Leading edge performers • Non-standard • Market competitive • Proprietary • These are conflicting in many ways!
  72. 72. Embedded design requirements cont… • Algorithm partitioning depends on the choice of processor used in the design – Several hundreds to choose from! • Choice of CPU impacts the partitioning decision which impacts the tools decisions, etc…
  73. 73. Embedded design requirements cont… • Variety of possible choices • Experience required to arrive at optimal design • Solution surface is smooth – Adequate solution not far off from the best solution • Constraints dictate the decision path
  74. 74. Iteration and implementation • Hardware and software paths begin to diverge • Early design work before the walls go up (between H/W and S/W) • Design still very fluid • Major blocks partitioned – Boundary can still be moved • Iteration is common
  75. 75. Iteration and implementation • Hardware team – Simulation tools to model performance • Software team – Running code benchmarks on self contained systems (evaluation boards) – Convenient development environment until the hardware arrives! • Tools are helping (keep h/w, s/w engaged longer) • More tools on their way…
  76. 76. Hardware/software integration • Special tools and methods to manage the complexity • Process of integrating h/w and s/w requires debugging and discovery –Did the software team really understand the hardware spec?
  77. 77. Hardware/software integration • Real-time nature of embedded systems leads to highly complex, non-deterministic behavior – Can only be analyzed as it occurs • Accurately modeling and simulating behavior may be very time consuming – But tools are getting better!
  78. 78. Product testing and release • Testing is important when performance is key • Testing and reliability more stringent Is system performing at close to its optimal capabilities?
  79. 79. Compliance testing • Embedded systems radiate a lot of radio frequency energy – “all electronic devices must be turned off…” • If embedded designer does not consider these things, compliance engineering (CE) will fail – Software must be running to pass this test – This is often overlooked
  80. 80. Maintaining and upgrading • Not many tools to support applications already in the field • 60% of embedded engineers maintain systems – Original engineer long gone – Must rely on experience, any existing documentation, etc… – Tools might be handy…
  81. 81. Maintaining and upgrading “time to market” must become “time to reverse engineer” and “time to insight”
  82. 82. Systems Product Life Cycle

×