RE for Embedded Systems - Part 1

Transcription

1 REQUIREMENTS ENGINEERING LECTURE 2017/2018 Dr. Jörg Dörr RE for Embedded Systems - Part 1 Fraunhofer IESE

2 Lecture Outline Embedded systems and their characteristics Requirements specifications (for embedded systems) Embedded-systems software specification

3 Some application domains Requirements Engineering Automobiles Aviation Railway Consumer Electronics Military

4 Characteristics Microprocessor-based and operates within a larger system Interaction with the environment - Often directly Application-specific control logic - Complex functionality e.g. flight control - Execution of specific tasks e.g. cameras - Specific hardware (ASIC, Microcontroller, FPGA, etc.) Constrained for resources - Limited memory - Limited power Battery operated Low heat dissipation Sophisticated power management. - Limited area Low manufacturing costs Portable

5 A closer look A/D conversion Memory (Software) CMOS Light Sensor Electronic shutter (Actuator) D/A conversion ASIC / FPGA Microprocessor

6 A closer look SW 1 SW 2 Memory Env. Input Sensors A/D P ASIC FPGA D/A Actuators Output To Env. Physical System Boundary Environment

7 Additional characteristics Requirements Engineering Real-time behavior - Button pressed do task by deadline. - Real-time does not mean fast Event-driven/ reactive behavior - Shutter pressed Open Lens - Always ready for reaction to external event. Concurrent behavior - Move Window Up, Set Cruise Speed Communicating processes - Set child lock, Open rear door Non-functional guarantees - Safety: If the brake is pressed, the car does not accelerate - Performance: Process 100 requests per minute - Dependability: Failure rate 10-4 failures / month - Fault Tolerance - Not a property; rather a means for achieving dependability Other means include fault prevention, fault masking, etc.

8 Outline Embedded systems and their characteristics Requirements specifications (for embedded systems) Embedded-systems software specification

9 Requirements specifications Requirements Engineering What are specifications? - Specifications state the requirements for a machine which, when correctly implemented, will achieve the desired change in the environment. - Accurate description of what the machine must do at its interface to its environment. E.g. If loss of separation is detected, issue an alert warning This is one specification statement for a requirement on allowable separation between aircraft in flight

10 Requirements categories Functional Non-functional - Performance - Resource consumption - Dependability Safety Reliability Maintainability Integrity Availability Requirements Engineering Other categories also exist.

11 Outline Embedded systems and their characteristics Requirements specifications (for embedded systems) Embedded-systems software specification

12 Embedded System Software Specification Logical system model What is the system? Where is the system boundary? What should be considered? Specification model What does the specification contain? What should be documented? Specification processes What steps to perform and how? Cleanroom software engineering Sequence-based Specification Specification methods How to document? Tables What language to use? SCR

13 Logical system model Requirements Engineering Env. Input A/D Controller (HW + SW) D/A Output To Env. Sensors Input devices Actuators Output devices Environment

14 Embedded System Software Specification Logical system model What is the system? Where is the system boundary? What should be considered? Specification model What does the specification contain? What should be documented? Specification processes What steps to perform and how? Cleanroom software engineering Sequence-based Specification Specification methods How to document? Tables What language to use? SCR

15 Specification model Environment Input Device Boundary Controller System Boundary Output Device Boundary M(t) IN I(t) SOF O(t) OUT C(t) Logical System Boundary REQ, NAT

16 Specification model System requirements document - AKA System requirements specification (SRS) - Black-box view of the system - Description of the environment Constraints from the environment e.g., physical laws - Constraints relevant for the machine to be built - Assumptions Document whose content is defined by mathematical relations David Parnas and Jan Madey. Functional Documents for Computer Science. Science of Computer Programming, Elsevier, 1995 Informally known as the Four Variable Model

17 Before we continue Elementary set-theoretic concepts - Relation AH: Set of {Age, Height}: {{20, 170}, {25,170}, {30,180}, {35,185}} - Function NA: Set of {Name, Age}: {{A, 20}, {B, 25}, {C, 30}, {D, 35}} A well-behaved relation - Domain For a function f or a relation r domain Dom (f ) or Dom (r ) : X-values Dom(AH): {20, 25, 30, 35} - Range For a function f or a relation r range Ran (f ) or Ran (r ) : Y-values Ran(NA): {20, 25, 30, 35}

18 4 variable model variables Requirements Engineering Monitored variables m i (t) - Variables whose values influence output of the machine / system - Exist outside the system boundary Often physical quantities - Values often vary with time Mathematically - m(t): R Value m : function assigning a time dependent real value. - M(t) : {m 1 (t), m 2 (t),, m n (t)} : Vector of monitored variables

19 4 variable model variables Requirements Engineering Controlled variables c i (t) - Variables whose values are determined by the system - Exist outside the system boundary Often physical quantities - Values often vary with time Mathematically - c(t): R Value c : function assigning a time dependent real value. - C(t) : {c 1 (t), c 2 (t),, c n (t)} : Vector of controlled variables

20 Specification model Environment Input Device Boundary Controller System Boundary Output Device Boundary M(t) IN I(t) SOF O(t) OUT C(t) Logical System Boundary REQ, NAT

21 4 variable model variables Requirements Engineering Input variables - Input variables i i (t) Variables whose values are the result of measurement of m i (t) Output variables o i (t) Variables whose values are the result of computation by the machine For all ( ) m i (t) there exists ( ) a corresponding i i (t) c i (t) o i (t) - Vice-versa need not be true - Often i i (t) and o i (t) will be discrete and digital If the machine is HW/SW control logic

22 Specification model Environment Input Device Boundary Controller System Boundary Output Device Boundary M(t) IN I(t) SOF O(t) OUT C(t) Logical System Boundary REQ, NAT

23 4 variable model relations Requirements Engineering NATural constraints expressed as a relation between the vectors of monitored variables M(t) and controlled variables C(t) - Dom (NAT): values of M(t) - Ran (NAT): values of C(t) - {M(t), C(t)} NAT if and only if (iff) environment (nature) permits the behavior

24 4 variable model relations Requirements Engineering REQuirements specified as a relation between the vectors of monitored variables M(t) and controlled variables C(t) - Dom (REQ): values of M(t) - Ran (REQ): values of C(t) - {M(t), C(t)} REQ iff system should permit the behavior

25 4 variable model more relations INput device description is a relation between monitored variables M(t) and Input variables I(t) OUTput device description is a relation between output variables O(t) and controlled variables C(t) SOFtware requirements specified as a relation between Input variables I(t) and output variables O(t) - Dom (SOF): values of I(t) - Ran (SOF): values of O(t) - {I(t), O(t)} SOF iff software should permit the behavior

26 Properties This should ALWAYS be true - Dom (REQ) (is superset of) Dom (NAT) or document is incomplete - If (Dom (NAT REQ) = Dom (NAT) Dom (REQ)) also holds then REQ is considered feasible with respect to NAT Else system breaks laws of nature Software behavior is acceptable if M(t), C(t), I(t), O(t) [IN(M(t), I(t)) SOF(I(t),O(t)) OUT(O(t), C(t)) NAT(M(t), C(t))] REQ(M(t), C(t))

27 4 variable model Summary Requirements Engineering

28 Embedded System Software Specification Logical system model What is the system? Where is the system boundary? What should be considered? Specification model What does the specification contain? What should be documented? Specification processes What steps to perform and how? Cleanroom software engineering Sequence-based Specification Specification methods How to document? Tables What language to use? SCR

29 Box-Structure Development Process How do we begin with specification (of embedded systems / software)? - Identify system boundary Interfaces - Input - Output - Define what is true at system boundary Relation between input and output - Define constraints on the system Also a relation between input and output

30 Cleanroom software engineering A process for developing and certifying high-reliability software Foundations - Software specifications are mathematical functions mapping a domain set to a range set. - Software programs are rules for computing this mathematical function - Well defined functions are complete, consistent and correct

31 Cleanroom software engineering Completeness - A response is defined for every input (or input history) - Each element of the domain set mapped to at least one element of the range set Consistency - Each element of the domain set mapped to exactly one element of the range set Correctness - Requirement vs. Specification - Judgment vs. Proof/ Reasoning - Explicit traceability

32 Cleanroom software engineering Key process activities - Incremental box-structure development Function-based specification and refinement - Statistical process control - Verification - Certification We will look at this today

33 Function based specification Requirements Engineering Incremental development by refinement Verification to check if refinement satisfies abstraction Recursive usage in the same order

34 Function based specification Requirements Engineering S: Stimulus SH: Stimulus history R: Response State and procedure free Specification of usage history - Document sequences of stimuli - Document required behavior for all possible combination of stimuli Required for analysis and agreement before committing resources Definition of behavior to be implemented Definition of behavior to be expected during testing Specify Black box behavior using sequence based specification (SBS)

35 Function based specification Requirements Engineering Definition of state-space Semantics (Old State, S) (New State, R) State preserves stimulus history Many possible state boxes for a given black box Abstraction is important

36 Function based specification Requirements Engineering Clear box: State box by procedure - Sequence do f1; f2 enddo - Alternative if c then f1 else f2 endif - Iteration while c do f1 enddo - Concurrence do f1 f2 enddo This is traditionally done AFTER specification i.e. development

37 Embedded System Software Specification Logical system model What is the system? Where is the system boundary? What should be considered? Specification model What does the specification contain? What should be documented? We looked at these until now Specification processes What steps to perform and how? Cleanroom software engineering Sequence-based Specification Specification methods How to document? Tables What language to use? SCR

38 Embedded System Software Specification Logical system model What is the system? Where is the system boundary? What should be considered? Specification model What does the specification contain? What should be documented? Specification processes What steps to perform and how? Cleanroom software engineering Sequence-based Specification Specification methods How to document? Tables What language to use? SCR Next section & next class on Example on SBS