SEng 5861: Software Architecture

1. SEng 5861: Software Architecture Lecture 5 Dr. Michael Whalen SEng 5861 - Mike Whalen

2. Topics for Today • Questions / Comments from Last Week • ATAM artifacts from last week • Project Pitches • If there is time: • Real-Time Systems Concepts • Architecture Description Languages • AADL SEng 5861 - Mike Whalen

3. Real-Time Architecture Modeling SEng 5861 - Mike Whalen

4. Real-Time Architectures A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed. In a hard real-time or immediate real-time system, the completion of an operation after its deadline is considered useless - ultimately, this may cause a critical failure of the complete system. A soft real-time system on the other hand will tolerate such lateness, and may respond with decreased service quality (e.g., omitting frames while displaying a video). http://en.wikipedia.org/wiki/Real-time_computing SEng 5861 - Mike Whalen

5. Traditional Domains of Concern SEng 5861 - Mike Whalen

6. Recent Domains of Concern SEng 5861 - Mike Whalen

7. Structure of sampling system Often called “Plant” System Actuators Sensors Controller SEng 5861 - Mike Whalen

8. Key Ideas of Sampling Systems • Repeatedly sample inputs, assess system state, and generate system outputs • Rate at which this cycle occurs is called sampling rate or period • Often approximating continuous assessment (i.e., differential equations) • Sampling rate must be “fast enough” to provide good approximation • Sampling rate depends on the rate of change for the system • Perform bounded amount of work per cycle • have to process the next sample! • Need to be able to finish within sample time • Longest time to process is called worst case execution time (WCET) • End-to-end latency is also important • Controller must have accurate view of system • Actuators must react “fast enough” SEng 5861 - Mike Whalen

9. Real-time concepts: Tasks • Separately scheduled units of work: also called threads • Often, multiple tasks are involved in a real-time system • A process describes a set of threads that share an address space. Each thread is a task. • May run at different sampling rates • Usually specified in cycles-per-second (Hertz) • Need to be scheduled to run on one or multiple CPUs • Several scheduling algorithms can be used • May have communication dependencies with other tasks SEng 5861 - Mike Whalen

10. Real-time concepts: Scheduling • Several real-time scheduling algorithms exist: • RMA: Rate-monotonic analysis scheduling • DMA: Deadline-monotonic analysis • Algorithms take (as input): • Per task: period, WCET • Per processor/OS: worst case thread context switch, process context switch • Additional information (e.g. frame dependencies, soft constraints) • Frame dependencies define ordering constraints for tasks within a frame (schedulable period) • Algorithms create either guaranteed schedule or abort (no schedule possible) SEng 5861 - Mike Whalen

11. Real-time concepts: Scheduling • Usually have polling (cyclic)tasks • May also have event-based tasks • Called aperiodic tasks • Require minimum delay between events to schedule SEng 5861 - Mike Whalen

12. Real-time concepts: end-to-end latency • Data flows through controller from inputs to outputs • May go through several intermediate tasks • End to End Latency describes the amount of time required for end-to-end flow • Frame dependencies change end-to-end latencies • Mid-frame communications have less latency • Phase-delayed communications have more SEng 5861 - Mike Whalen

13. Real-time concepts: Communication • Several mechanisms for communication between processes • Logical views: • Message queue / pipe • Rendezvous • Remote procedure call • Physical views: • Shared memory • Interrupt • Bus • Network SEng 5861 - Mike Whalen

14. Dependability • Dependability is the quality of delivered service such that reliance can justifiably be placed on the service • Service is the system behavior as it is perceived by the user of the system • A failure occurs when the delivered service deviates from the service specification that describes the desired service • An error is that part of the system state that can lead to a failure. Errors can be latent or effective (active). • A fault is the root cause of the error. It can be human caused (e.g. a programmer’s mistake) or physical (e.g. a short-circuit) SEng 5861 - Mike Whalen

15. Dependability • From the other direction: • Faults (e.g. programmer’s mistake) are the cause of • Latent errors (e.g., a line of code with a bug in it) which become • Effective errors if the system reaches a state where the error can manifest (e.g. executing the line of code containing a bug), which may cause • Failures if the error causes a visible deviation from service from the user’s perspective (e.g. the program crashes). SEng 5861 - Mike Whalen

16. Dependability • Achieving a dependable system involves utilizing four kinds of methods: • Fault avoidance: preventing, by construction, fault occurrence, • Fault tolerance: providing, by redundancy, service complying with specification despite faults having occurred or occuring • Error removal: how to minimize, by verification, the presence of latent errors, and • Error forecasting: how to estimate, by evaluation, the presence, the creation, and the consequences of errors. SEng 5861 - Mike Whalen

17. Dependability SEng 5861 - Mike Whalen

18. Real-time concepts recap • Possible to study issues here for a lifetime! • Designed to provide enough information to understand RTS architectural concerns and AADL • Much more depth in the real-time systems elective class (SEng5831) SEng 5861 - Mike Whalen

19. ArchitectureDescription Languages SEng 5861 - Mike Whalen

20. ADLs • Language for viewing and analyzing “architectural” software concerns • Describes structure of system rather than (functional) implementation • Subject of much research in late 1990s and early 2000s • Many academic ADLs • …and of course, UML • Wide range of ADLs for different kinds of software SEng 5861 - Mike Whalen

21. ADLs • ADLs ≈ Multi-model architecture notations • Overview paper: • “A classification and comparison framework for Architecture Description Languages” by Medvidovic and Taylor • http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.151.4061&rep=rep1&type=pdf • We have seen one (UML) in some depth already • Doesn’t have (agreed upon) semantics, though • Difficult to use for analysis and architecture generation SEng 5861 - Mike Whalen

22. Why Use ADL? This looks awfully familiar • Help us understand the situation being modeled. • Designed for analysis and reasoning to draw conclusions about the performance of the model • Designed to ensure consistency between different system views • Often designed to generate system skeleton from model • Medium of communication. • ADLs reduce the amount of information the reader needs to understand, and they should structure the information in a “good” way. • Help us organize our processes, teams, and deliverables based on the structures revealed in the model. • ADs can be built directly from ADLs SEng 5861 - Mike Whalen

23. Two Architecture World Views • Bottom up (assembly): • Architecture description is assembled from viewpoints that describe different facets of architecture • Top down (generative): • Architecture specification (in ADL) is used to generate different viewpoints (via extraction) to present information of interest to stakeholders • Can also generate implementation skeletons SEng 5861 - Mike Whalen

24. Language Focus and Applications SEng 5861 - Mike Whalen

25. ADL Support for Modeling Components • Interface • A component’s interface is a set of interaction points between it and the external world • Types • Component types are abstractions that encapsulate functionality into reusable blocks • Semantics • High-level model of a component’s behavior • Constraints • A property of or assertion about a system or one of its parts • Evolution • The modification of (a subset of) a component’s properties, e.g., interface, behavior, or implementation • Non-Functional Properties • Properties that effect safety, security, performance, portability SEng 5861 - Mike Whalen

26. ADL Support for Modeling Connectors • Interface • A set of interaction points between the connector and the components and other connectors attached to it. • Types • Abstractions that encapsulate component communication, coordination, and mediation decisions • Semantics • High-level model of a connector’s behavior • Constraints • Ensure adherence to intended interaction protocols, establish intra-connector dependencies, and enforce usage boundaries • Evolution • The modification of (a subset of) its properties, e.g., interface, semantics, or constraints on the two • Non-Functional Properties • Properties that represent (additional) requirements for correct connector implementation SEng 5861 - Mike Whalen

27. ADL Support for Modeling Configurations • Understandable Specifications • model structural (topological) information with simple and understandable syntax. • Compositionality • A mechanism that allows architectures to describe software systems at different levels of detail • Refinement and Traceability • Enable correct and consistent refinement of architectures into executable systems and traceability of changes across levels of architectural refinement • Heterogeneity • Facilitate development of large-scale systems • Pre-existing components and connectors of varying granularity • Different formal modeling languages and programming languages • Varying operating system requirements • Different communication protocols • Scalability • Provide developers with abstractions needed to cope with the issues of software complexity and size. • Evolvability • Incremental addition, removal, replacement, and reconnection in a configuration • Dynamism • Modifying the architecture and enacting those modifications in the system while the system is executing • Constraints • Depict dependencies in a configuration complement those specific to individual components and connectors • Non-Functional Properties • Used to select appropriate components and connectors, perform analysis, enforce constraints, map architectural building blocks to processors, and aid in project management. SEng 5861 - Mike Whalen

28. AADL SEng 5861 - Mike Whalen

29. AADL Overview • Switch to “AADL V2 Overview Feb 2010.pptx” SEng 5861 - Mike Whalen

30. Analysis Using AADL • This is really the point of using the notation! SEng 5861 - Mike Whalen

31. An Example: MFD Hosted: DM: MFD Display Manager WAM: Warning and Annunciations Manager PCM: Page Content and Menu Manager FD: Flight Director Mission Hosted: CM: Communications Manager WM: Weapons Manager SA: Situational Awareness FM: Flight Manager MSM: Mission Sensor Manager 1553: Software Interface to MIL STD 1553 bus SEng 5861 - Mike Whalen

32. An Example: Are DMs , WAMs, etc. , redundant or unique? MFD Hosted: DM: MFD Display Manager WAM: Warning and Annunciations Manager PCM: Page Content and Menu Manager FD: Flight Director Mission Hosted: CM: Communications Manager WM: Weapons Manager SA: Situational Awareness FM: Flight Manager MSM: Mission Sensor Manager 1553: Software Interface to MIL STD 1553 bus How is data replicated between redundant mission processors and MFD processors What are the delays of certain signal paths? SEng 5861 - Mike Whalen

33. Model in AADL to Clarify Architecture • AADL Allows straightforward, precise modeling of current system and possible changes to system • Can discuss schedulability, reliability, etc. • Can use built-in analyses to provide quantified information SEng 5861 - Mike Whalen

34. Initial Model: Scheduling this “task” with others is difficult Must run at 20Hz and worst case execution time is high SEng 5861 - Mike Whalen

35. Flow Communication SEng 5861 - Mike Whalen

36. A Priority-Based Approach Priority inversion here. PG *needs* to run more often than IN, but can’t pre-empt it. Difficult to schedule! Representing data dependencies as priorities is a poor way to schedule tasks. SEng 5861 - Mike Whalen

37. Dataflow-based scheduling Flow-based analysis allows mid-frame dependencies added to schedule constraints. Represent problem directly and get better resource utilization. SEng 5861 - Mike Whalen

38. Polling or Event-Based? • Current system uses polling for all tasks • Polling processes allow simple scheduling algorithms • Maintains periodicity of threads to be scheduled • However, polling is very inefficient for certain tasks, like monitoring user interface elements • Switches, keyboard • Have to set polling rate high enough that no state change is missed. • Also want high rate to reduce latency • But most of the time, it does nothing. • But…events can cause missed deadlines SEng 5861 - Mike Whalen

39. Sporadic events • AADL allows scheduling of sporadic events • Specified minimum time between events • Efficiency gains: • Reduce number of concurrent monitors of events (not all buttons can be pressed at once) • If event processing is not a “hard” real time problem, possible to gain further utilization in scheduling SEng 5861 - Mike Whalen

40. Managing Latency Flow-based analysis allows mid-frame dependencies added to schedule constraints to both threads and partitions. SEng 5861 - Mike Whalen

41. Managing Latency SEng 5861 - Mike Whalen

42. Communicating Redundancy SEng 5861 - Mike Whalen

43. Communicating Redundancy SEng 5861 - Mike Whalen

44. Describing Fault Tolerance SEng 5861 - Mike Whalen

45. What have we learned? • You tell me! SEng 5861 - Mike Whalen

46. What have we learned? • An overview of real-time architecture concepts • The role of time on application structure • How real-time concerns affect architecture partitioning • Logical/physical views of real-time systems • AADL and architecture description languages • (Hopefully) each group has presented a management pitch! SEng 5861 - Mike Whalen