Download - Real-Time System Requirements & Design Specs
![Page 1: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/1.jpg)
Real-Time SystemRequirements & Design Specs
Shaw - Chapters 3 & 4
Homework #2: 3.3.1,
3.4.1,
Add Error states to Fig 4.1
Lecture 4/17
![Page 2: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/2.jpg)
The Problem• We need to be able to describe a system
unambiguously and prove that it can meet desired criteria before we begin the design.
• Unfortunately the reality is that for almost all practical systems, the complexity and the scale of the system makes this extremely difficult if not virtually impossible, at least with today’s tools and methodologies.
• Concurrency can easily produce race conditions. Mutual exclusion solutions can produce deadlocks or starvation. Etc.
![Page 3: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/3.jpg)
Practical Approaches?
• Behaviors for many scenarios of interest can be demonstrated through simulation or prototyping.
• Executable “specifications” can be useful for clarifying or refining requirements and designs.
• Bottom up approaches often allow designs to evolve through increasingly adding complexity to proven simplified models and subsystems.
![Page 4: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/4.jpg)
Imperative vs Declarative Specs
• Imperative specs specify system behaviors in terms of algorithmic descriptions. These can be visualized and translated into computer procedures and prototypes, supporting rapid prototyping.
![Page 5: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/5.jpg)
Imperative vs Declarative Specs• Declarative descriptions specify properties
that must be satisfied by the system. It is usually easier to prove properties with these descriptions, but more difficult to use them to generate designs.
• Declarative descriptions specify properties that must be satisfies by the system. It is usually easier to prove properties with these descriptions, but more difficult to use them to generate designs.
![Page 6: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/6.jpg)
Some Approaches Shaw Explores
• Data Flow Diagrams: Provides an attractive visualization which can be easily developed and evolved by a team.
• Tabular Languages: Provides a way to express and communicate a lot of requirements in a comprehensive and complete process.
• State Machines: State machines have proven to be a language of choice for many traditional modeling and design projects. A number of adaptations have been proposed and used effectively in real-time system designs.
![Page 7: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/7.jpg)
Some Approaches Shaw Explores
• Formal Methods: Sophisticated mathematical techniques can provide powerful description and verification of systems, for example:– Regular expressions– Propositional Logic– Predicates– Temporal Logic
![Page 8: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/8.jpg)
Data Flow Diagrams
• They are based on a familiar tool
• They provide an attractive visualization which can be easily developed and evolved by a team.
![Page 9: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/9.jpg)
Data Flow Diagrams (DFD)
![Page 10: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/10.jpg)
DFD Example
![Page 11: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/11.jpg)
DFD Example
![Page 12: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/12.jpg)
DFD Deficiencies
• Lack of control information
• Lack of timing
• Lack of scheduling specification
![Page 13: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/13.jpg)
Tabular languages
• They provide a way to express and communicate a lot of requirements in a comprehensive and complete process.
• They nicely tabulate Conditions and Actions
• They are easily expanded, partitioned, and simplified.
![Page 14: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/14.jpg)
Tabular Languages
![Page 15: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/15.jpg)
Example of Tabular Language
![Page 16: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/16.jpg)
Example Tabular Language
![Page 17: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/17.jpg)
Tabular Language Deficiencies
• Timing and logical constraints are listed separately
• There does not appear to be an obvious way to include concurrency and timing in an effective way.
![Page 18: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/18.jpg)
Finite State Machines
• State machines have proven to be a language of choice for many traditional modeling and design projects. A number of adaptations have been proposed and used effectively in real-time system designs.
• We will look at one approach Communicating Real-Time State Machines (CRSM)
![Page 19: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/19.jpg)
FSM Example
![Page 20: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/20.jpg)
FSM Example
![Page 21: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/21.jpg)
Allowing Outputs in FSM
![Page 22: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/22.jpg)
Chapter 4 Systems of State Machines
• Communicating Real-Time State Machines
• An attempt to create a complete executable design specification language
• Time is integral to the language
![Page 23: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/23.jpg)
CRSMs
• CSRMs are state machine with guarded commands for transitions, synchronous communicating senders and receivers, and explicit time restrictions.
• A complete CSRM system contains both a simulation of the internal system and its external environment.
• They are an extension of Tony Hoare’s classical Communicating Sequential Processes
![Page 24: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/24.jpg)
Terminology
Denotes the timing constraint, i.e. the lower tmin and upper tmax bounds on time allowed during the transition. Then for an execution or deadline d,
0 <= tmin <= d <= tmax
![Page 25: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/25.jpg)
Terminology
Communication:
• Communicating Channel name: channel
• Sending a message over channel: channel(message)!
• Receiving a message through channel: channel(target)?
Effect is equivalent to an assignment: target := message
![Page 26: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/26.jpg)
CRSM Timing
M1 (sender) enters state U at time Tu, and M2 (Receiver) enters state X at Tx :
I/O must occur between Tu+a and Tx+d or CRSM will transition to an error state
![Page 27: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/27.jpg)
Bounded Buffer Example
![Page 28: Real-Time System Requirements & Design Specs](https://reader035.vdocuments.site/reader035/viewer/2022062315/56814ef2550346895dbc817f/html5/thumbnails/28.jpg)
Mouse Click Example