2. Lecture 2 Specification and Requirement Analysis of Embedded System

3. שלבי פיתוח המערכת

4. Specification of embedded systems: Requirements for specification techniques 1. Hierarchy Humans not capable to understand systems containing more than ~5 objects. Most actual systems require more objects  Hierarchy Behavioral hierarchy Examples: states, processes, procedures. Structural hierarchy Examples: processors, racks, printed circuit boards proc

5. 2. Timing behavior. 3. State-oriented behavior Required for reactive systems; classical automata insufficient. 4. Event-handling (external or internal events) 5. No obstacles for efficient implementation 6. Support for the design of dependable systems Unambiguous semantics,... 7. Concurrency Real-life systems are concurrent 8. Synchronization and communication Components have to communicate!

6. 9. Exception-oriented behavior Not acceptable to describe exceptions for every state. We will see, how all the arrows labeled k can be replaced by a single one. 10. Presence of programming elements For example, arithmetic operations, loops, and function calls should be available 11. Executability (no algebraic specification) 12. Support for the design of large systems (  OO) 13. Domain-specific support

7. 14. Readability 15. Portability and flexibility 16. Termination It should be clear, at which time all computations are completed 17. Support for non-standard I/O devices Direct access to switches, displays,.. 18. Non-functional properties fault-tolerance, disposability, weight, size, user friendliness, extendibility, expected life time, power consumption... 19. Adequate model of computation

8. דוגמא – מערכת רמזורים א. תיאור כללי של המערכת: המערכת הממוחשבת מטפלת בניהול רמזורים ומצלמות בצומת כבישים מרכזי בעיר. הצומת כולל 2 כבישים דו-נתיביים דו-מסלוליים המצטלבים בצומת. ראה ציור. בצומת קיימים: 4 רמזורי רכב המטפלים בתנועת הרכב בכיוונים האפשריים 4 חישנים לחישת רכבים בצומת 4 רמזורים להולכי רגל עם כפתורי הפעלה 2 מצלמות הממוקמות על עמודי תאורה ומצלמות את הנעשה בצומת ומעבירים מידע למרכז בקרה שאינו חלק מהמערכת. כל הרמזורים, המצלמות, החישנים וכפתורי ההפעלה מןפעלים ע"י מעבד יחיד השולט על המערכת ומתואר במסמך זה.

9. המשך דוגמא ב. קלט: הקלטים של המערכת הם: 1.תנועת הרכבים הנקלטת ע"י החיישנים 2.לחיצה על כפתורי ההפעלה של רמזורי הולכי הרגל 3.הוראות מבקרת הרמזורים ג. פלט: פקלטים של המערכת הם: 1.הפעלת רמזורי המכוניות 2.הפעלת רמזורי הולכ רגל 3.הוראות תזוזה למצלמות ( ההנחה שמנוע הגבהה וצידוד של המצלמות לא חלק מהמערכת) 4. הודעות למרכז הבקרה

10. המשך דוגמא ד. תיאור תרחישים ואילוצים: 1.המע' תבצע את פעולתה בהתאם לחוקי תעבורה בנוגע לתנועת רכבים 2.המע' לא תאפשר אור ירוק למסלולים מתנגשים 3.נמע' לא תאפשר אור ירוק להולכי רגל יחד עם אור ירוק למכוניות 4.כאשר אין הולכי רגל, תנתן עדיפות למכוניות 5.כשאין עומס מכוניות (פחות מ-20 בדקה) המע' תחלק באופן שווה את המעבר בצומת בין כל המסלולים 6.בזמן עומס, המע' תגדיל אור ירוק לנתיב פרופורציונלית לעומס 7.כאשר מבוצעת לחיצה על כפתור לחיצה רמזורי הולכי רגל, המע' תבדוק את עומס התנועה, במידה ולא עברו מכוניות בצומת במשך 5 שניות, המע' תאפשר מעבר להולכי רגל ותשנה שוב את מצבה בעוד 20 שניות. במידה ולא נמצא חלון זמן פנוי במהלך 3 דקות אחרונות, תאפשר המע' מעבר בטוח בכל מקרה.

11. המשך דוגמא 8. מצלמות הוידאו יכוונו ל-2 המסלולים העמוסים ביותר כל הזמן. יש למנוע תזוזת יתר של המצלמה, כי המנוע נשחק, לכן יעברו 3 שניות בין תזוזות. שתי מצלמות לא יכוונו לאותו נתיב. 9.מרכז הבקרה רשאי לשלוח פקודה למצלמה ולכוונה למסלול מסויים. נדרשת פקודה נוספת על מנת לשחרר שיעבוד זה. עם קבלת פקודה ממרכז הבקרה, תעבור המצלמה תוך 3 שניות לזוית זו. עם שחרור השיעבוד המצלמה תחזור לנתיב העמוס ביותר שאין שם מצלמה שניה. 10.מרכז הבקרה יכול לשלוח שאילתות, מצפה לתשובה תוך 1 שניות. שאילתת עומס: התשובה תכלול את העומס הממוצע של כלי הרכב במשך 5 דקות האחרונות בכל נתיב. שאילתת תקינות: כתגובה המע' תבצע Build In Test (BIT) ותחזיר כן/לא.

12. המשך דוגמא ה. תיאור הממשק למשתמש: 1.הרמזורים והכפתורים יוצגו בצורה גרפית על המסך 2.לחיצה על עכבר תדמה לחיצה על כפתור רמזור הולכי רגל 3.נתוני התנועה (מס מכוניות מכוניות לשניה בכל מסלול) יתקבלו כקובץ קלט 4.מצלמות יוצגו גרפית בעזרת זוית הצילום 5.פקודות מרכז הבקרה יוצגו ע"י טקסט

13. Final project The students will develop a small embedded system in the following steps: 1.Analysis 2.Design 3.Implementation 4.Testing and verification

14. בבחירת נושא הפרוייקט יש לשים לב: קלט ופלט מתרחשים בזמן אמת שחקנים מרובים במע' שנשלטים ע"י מע' ופועלים באופן בלתי תלוי. יש לקחת בחשבון את כל הארועים ותרחישים אפשריים. הם יכולים לקרות בצורה בלתי תלויה זה בזה. יש להגדיר deadline מדוייקים במספרים יש להתחשב באפשרות תקלה, איחור deadline יש לדאוג לבקרה עצמית

15. תרגיל 2 תרגיל הגשה לאחרי שבועות 16.6: לבחור נושא הפרוייקט ולהכין מסמך ניתוח דרישות

16. Models of computation define: –Components and an execution model for computations for each component –Communication model for exchange of information between components.

17. State Chart Classical automata: Internal state Z input Xoutput Y clock Classical automata not useful for complex systems (complex graphs cannot be understood by humans). An addition of hierarchy to automata is the StateChart

18. State Chart: hierarchy FSM will be in exactly one of the substates of S if S is active (either in A or in B or..)

19. –Current states of FSMs are also called active states. –States which are not composed of other states are called basic states. –States containing other states are called super-states. –For each basic state s, the super-states containing s are called ancestor states. –Super-states S are called OR-super-states, if exactly one of the sub-states of S is active whenever S is active. State Chart: definitions ancestor state of E substates superstate

20. Try to hide internal structure from outside world!  Default state Filled circle indicates sub-state entered whenever super-state is entered. Not a state by itself! State Chart: default state

21. For input m, S enters the state it was in before S was left (can be A, B, C, D, or E). If S is entered for the very first time, the default mechanism applies. History and default mechanisms can be used hierarchically. (behavior different from last slide) km State Chart: history

22. same meaning State Chart: combining history and default state

23. Convenient ways of describing concurrency are required. AND-super-states: FSM is in all (immediate) sub-states of a super-state; Example: State Chart: concurrency

24. Line-monitoring and key-monitoring are entered and left, when service switch is operated. incl. State Chart: entering and leaving AND-super-states

25. In StateCharts, states are either –basic states, or –AND-super-states, or –OR-super-states. State Chart: types of states

26. Since time needs to be modeled in embedded systems, timers need to be modeled. In StateCharts, special edges can be used for timeouts. If event a does not happen while the system is in the left state for 20 ms, a timeout will take place. State Chart: timers

27. State Chart: using timers in answering machine

28. Events: –Exist only until the next evaluation of the model –Can be either internally or externally generated Conditions: –Refer to values of variables that keep their value until they are reassigned Reactions: –Can either be assignments for variables or creation of events Example: –service-off [not in Lproc] / service:=0 event [condition] / reaction General form of edge labels

29. How are edge labels evaluated? Three phases: 1.Effect of external changes on events and conditions is evaluated, 2.The set of transitions to be made in the current step and right hand sides of assignments are computed, 3.Transitions become effective, variables obtain new values. Separation into phases 2 and 3 guarantees deterministic and reproducible behavior. The StateCharts simulation phases (StateMate model)

30. Example In phase 2, variables a and b are assigned to temporary variables. In phase 3, these are assigned to a and b. As a result, variables a and b are swapped. In a single phase environment, executing the left state first would assign the old value of b (=0) to a and b. Executing the right state first would assign the old value of a (=1) to a and b. The execution would be non-deterministic.

31. In an actual clocked (synchronous) hardware system, both registers would be swapped as well. Same separation into phases found in other languages as well, especially those that are intended to model hardware. Reflects model of clocked hardware

32. Execution of a StateMate model consists of a sequence of (status, step) pairs Status= values of all variables + set of events + current time Step = execution of the three phases (StateMate semantics) Status= values of all variables + set of events + current time Step = execution of the three phases (StateMate semantics) Status phase 2 phase 3 phase 1 Other implementations of StateCharts do not have these 3 phases (and hence are nondeterministic)!

33. StateChart: Broadcast Mechanism Values of variables are visible to all parts of the StateChart model. New values become effective in phase 3 of the current step and are obtained by all parts of the model in the following step.  StateCharts implicitly assumes a broadcast mechanism for variables.  StateCharts is appropriate for local control systems ( ), but not for distributed applications for which updating variables might take some time (  ).  StateCharts implicitly assumes a broadcast mechanism for variables.  StateCharts is appropriate for local control systems ( ), but not for distributed applications for which updating variables might take some time (  ).

34. Summary of StateChart Pros: –Hierarchy allows arbitrary nesting of AND- and OR-super states. –(StateMate-) Semantics defined in a follow-up paper to original paper. –Large number of commercial simulation tools available (StateMate, StateFlow, BetterState,...) –Available „back-ends“ translate StateCharts into C or VHDL, thus enabling software or hardware implementations.

35. Cons: –Generated C programs frequently inefficient, –Not useful for distributed applications, –No program constructs, –No description of non-functional behavior, –No object-orientation, –No description of structural hierarchy. Extensions:  Module charts for description of structural hierarchy. Extensions:  Module charts for description of structural hierarchy.

36. Some general properties of languages: Synchronous vs. asynchronous languages Synchronous languages implicitly assume the presence of a (global) clock. Each clock tick, all inputs are considered, new outputs and states are calculated and then the transitions are made. This requires a broadcast mechanism for all parts of the model. Idealistic view of concurrency. Has the advantage of guaranteeing deterministic behavior.  StateCharts is a synchronous language.

37. Some general properties of languages: Properties of processes Number of processes static; dynamic (dynamically changed hardware architecture?) Nesting: –Nested declaration of processes process { process { process { }}} –or all declared at the same level process { … } process { … } process { … }

38. Different techniques for process creation –Elaboration in the source declare process P1 … –explicit fork and join id = fork(); –process creation calls id = create_process(P1);  StateCharts comprises a static number of processes, nested declaration of processes, and process creation through elaboration in the source.

39. Some general properties of languages: Communication paradigms Message passing –Non-blocking communication Sender does not have to wait until message has arrived; potential problem: buffer overflow … send () … receive () …

40. –Blocking communication, rendez-vous-based communication Sender will wait until receiver has received message … send () … receive () …

41. send () … receive () … ack … –Extended rendez-vous Explicit acknowledge from receiver required. Receiver can do checking before sending acknowledgement.

42. Shared memory Variables accessible to several tasks Potential race conditions (  inconsistent results possible)  Critical sections = sections at which exclusive access to resource r (e.g. shared memory) must be guaranteed.  StateCharts uses shared memory for communication between processes. process a {.. P(S) //obtain lock.. // critical section V(S) //release lock } process b {.. P(S) //obtain lock.. // critical section V(S) //release lock } Race-free access to shared memory protected by S possible

43. Some general properties of languages: Specifying timing 4 types of timing specs required: Means for delaying processes t ? t execute Measure elapsed time Check, how much time has elapsed since last call

44. Possibility to specify timeouts Stay in a certain state a maximum time.  StateCharts comprises a mechanism for specifying timeouts. Other types of timing specs not supported. Methods for specifying deadlines Not available or in separate control file. t execute

45. Properties of specification languages: Using non-standard I/O devices Direct access to switches, displays etc; No protection required; OS can be much faster than for operating system with protection.  No support in standard StateCharts.  No particular OS support anyhow.

46. Graphical means for representing schedules; time used vertically, geographical distribution horizontally. No distinction between accidental overlap and synchronization Message sequence charts (MSC)

47. Time/distance diagrams as a special case © www.opentrack.ch

48. Example: setting up a TCP connection

49. Message sequence charts +Appropriate for visualizing schedules, +Proven method for representing schedules in transportation. +Standard defined: ITU-TS Recommendation Z.120: Message Sequence Chart (MSC), ITU-TS, Geneva, 1996. +Semantics also defined: ITU-TS Recommendation Z.120: Message Sequence Chart (MSC)—Annex B: Algebraic Semantics of Message Sequence Charts, ITU-TS, Geneva. –describes just one case, no timing tolerances: "What does an MSC specification mean: does it describe all behaviors of a system, or does it describe a set of sample behaviors of a system?”

50. Key problems observed with standard MSCs: During the design process, MSC are initially interpreted as “what could happen” (existential interpretation, still allowing other behaviors). Later, they are frequently assumed to describe “what must happen” (referring to what happens in the implementation). Key problems observed with standard MSCs: During the design process, MSC are initially interpreted as “what could happen” (existential interpretation, still allowing other behaviors). Later, they are frequently assumed to describe “what must happen” (referring to what happens in the implementation). Message sequence charts

51. Life Sequence Chart (LSC) Extension 1: Introduction of pre-charts: Pre-charts describe conditions that must hold for the main chart to apply. Extension 1: Introduction of pre-charts: Pre-charts describe conditions that must hold for the main chart to apply. Pre-chart Example:

52. Life Sequence Chart (LSC) Extension 2: Mandatory vs. provisional behavior LevelMandatory (solid lines)Provisional (dashed lines) Chart All runs of the system satisfy the chart At least one run of the system satisfies the chart LocationInstance must move beyond location/time Instance run need not move beyond loc/time MessageIf message is sent, it will be received Receipt of message is not guaranteed ConditionCondition must be met; otherwise abort If condition is not met, exit subchart

53. ≠ Message does not need to arrive Life Sequence Chart (LSC)

54. “run” does not need to continue Don’t enter main chart, if condition is not met. Life Sequence Chart (LSC)

55. Mandatory behavior can be used to generate StateCharts models from LSC models. LSCs enable link between “timing” spec and FSMs (no real link possible with standard MSCs). Provisional behavior can be checked against mandatory. Error messages can be generated of the two are not consistent. Provisional behavior can be checked against mandatory. Error messages can be generated of the two are not consistent.