Introduction to the World of Real-Time and Embedded Systems

1. Introduction to the World of Real-Time and Embedded Systems

2. Topics to discuss • What Is Special about Real-Time Systems • Time, Performance, and Quality of Service • Systems Engineering • ROPES Process • Working with Models • Organizing Models • Model-Based Development • Embedded Software design • Implementation&deployment • Embedded Software testing

3. What Is Special about Real-Time Systems? • Difference between desk top PC and Embedded Computers, e.g. toaster controller, washing machine, DVD player,…. • The software for these embedded computers is more difficult to construct than software for the desktop. Real-time systems have all the problems of desktop applications plus many more.

4. What Is Special about Real-Time Systems? • Real-time systems often do not have a conventional computer display or keyboard, but lie at the heart of some apparently noncomputerized device. • Such systems must often operate for days or even years without stopping, in the most hostile environments. • The services and controls provided must be autonomous and timely. Frequently, these devices have the potential to do great harm if they fail.

5. What Is Special about Real-Time Systems? • Real-time systems encompass all devices with performance constraints. • Hard deadlines are performance requirements that absolutely must be met. • Soft real-time systems are characterized by time constraints which can (a) be missed occasionally, (b) be missed by small time deviations, or (c) occasionally skipped altogether.

6. What Is Special about Real-Time Systems? • An embedded system contains a computer as part of a larger system and does not exist primarily to provide standard computing services to a user. • A desktop PC is not an embedded system, unless it is within a tomographical imaging scanner or some other device. A computerized microwave oven or VCR is an embedded system because it does no standard computing.

7. Time, Performance, and Quality of Service • In 2002, the Object Management Group (OMG) adopted the Unified Modeling Language™ (UML) profile that provided a standardized means for specifying timeliness, performance, and schedulability aspects of systems and parts of systems, the so-called Real-Time Profile (RTP)

8. Time, Performance, and Quality of Service • Modeling Actions and Concurrency • Most developers concerned with timeliness of behavior express it in terms of actual execution time relative to a fixed budget called a time constraint. • Hard:The correctness of an action includes a description of timeliness. A late completion of an action is incorrect and constitutes a system failure. • Soft:Average deadline and average throughput are common terms in soft real-time systems.

9. Systems Engineering vs. Software Engineering • The primary activities encompassed by systems engineering include • Capturing, specifying and validating the requirements of the system as a whole • Specification of the high-level subsystem architecture • Definition of the subsystem interfaces and functionality • Mapping the system requirements onto the various subsystems • Decomposing the subsystems into the various disciplines—electronic, mechanical, software, and chemical—and defining the abstract interfaces between those aspects

10. The Rapid Object-Oriented Process for Embedded Systems (ROPES) Process[ • The ROPES process exists on three time scales simultaneously: • Macro— The entire length of the project, typically one to several years • Micro— The time required to produce a single increment or version of the system that achieves some targeted functionality—typically four to six weeks • Nano— The time needed to produce, compile, execute, and/or test some very small portion of the system—typically 30 minutes to an hour

11. The Rapid Object-Oriented Process for Embedded Systems (ROPES) Process • macrocycle is divided up into four overlapping macrophases: • Key concepts • Secondary concepts • Design concepts • Optimization and deployment concepts

12. Model-Driven Development (MDD) • Iterative Development— Iterative development is based on the concept of incremental construction. • Use of Models— Large, complex systems can't be effectively constructed using only source-code-level constructs. • Model-Code Bidirectional Associativity— For model-based systems, it is absolutely crucial that the code and the diagrams are different views of the very same underlying model.

13. Executable Models— You can only test things that execute—therefore, build primarily executable things, both early and often. • Debug and Test at the Design Level of Abstraction— Because today's applications are extremely complex, we use abstract design models to help us understand and create them.

14. Test What You Fly and Fly What You Test— Simulation has its place, but the purpose of building and testing executable models is to quickly develop defect-free applications that meet all of their functional and performance requirements.

15. MDA and Platform-Independent Models • A model may support any number of different views. A UML class diagram may show a number of classes interacting together to realize a use case. • Another class diagram may show the same class in a generalization taxonomy. Still another class diagram may show how the class fits within its domain of interest.

16. MDA and Platform-Independent Models • An executable model is a model that is defined with a rich enough set of semantics that its execution behavior is predictable. One can argue that any model that can be represented ultimately as executable machine code is, in fact, an executable model. • MDA is an approach that separates aspects of a model that are independent of underlying technologies from those that are dependent upon those aspects.

17. MDA and Platform-Independent Models • The platform-independent model (PIM) is constructed to be independent of the processor(s) on which it runs, the communication infrastructure (such as Ethernet and TCP/IP), middleware (such as COM or CORBA), and even the implementation language (such as C or Ada).

18. Scheduling Model-Based Projects • Why Schedule? • When will the project be done? • How much will it cost? • Is this project likely to provide a good return on investment (ROI)? • Should I invest in this project or another project? • How many resources must I apply to it? • Do I need to hire people and if so, with what skills? • When should I begin ancillary activities, such as gearing up manufacturing, starting the marketing campaign, beginning the next project? • These are legitimate business questions and can

19. Scheduling Model-Based Projects • BERT and ERNIE • The ROPES process provides means for both constructing estimates and for improving one's ability to estimate. These (sub)processes are known as BERT and ERNIE. • The engineer estimating the work provides three estimates: • [24] Although it can be used for larger units early before the decomposition to smaller units has been made. • The mean (50%) estimate • The optimistic (20%) estimate • The pessimistic (80%) estimate

20. Working with Model-Based Projects • These questions should be answered by your company's (or project's) software development plan (SDP). • One of the key activities in the daily workings of a project is configuration management. In a model-based project, the primary artifact being configured with the CM system is the model.

21. Embedded Software Design • Architecture Analysis • Hardware Fundamentals (ARM)2 • Processor Instructions (ARM)3 • Getting Started • Interrupts • Detailed Design • Software Architectures • Peripherals • Real-time OS

22. Implementation • Real time OS concept and standard • Embedded OS, concept and standard, e.g. J2ME • Embedded programming, e.g. Lego + 手機etc.

23. Embedded Software Deployment • Installation • leJOS NXJ Lego OS + Development suite(JDK)+ • Porting • Borland Together code gen. • Loading

24. Embedded Software Testing • The TEmb method • planning the test project according a certain lifecycle, applying standardized techniques, dedicated test environments, organizing test teams, formal reporting, etc. • four cornerstones of structured testing: • lifecycle, infrastructure, techniques, organization.

25. Embedded Software Testing