Lecture notes Distributed Systems

distributed embedded system design and distributed embedded systems software architecture pdf free download
Dr.AstonCole Profile Pic
Dr.AstonCole,United Kingdom,Researcher
Published Date:10-07-2017
Your Website URL(Optional)
7 Distributed +Embedded Systems Distributed Embedded Systems Philip Koopman September 16, 2015 © Copyright 2000-2015, Philip KoopmanIntroduction  Time Trigger vs. Event Trigger • Two different approaches to networking  Distributed embedded systems – progression of ideas • Distributed power switching • Muxed control signals • Distributed computation • “Smart nodes” – an extreme case of distribution  Distributed vs. centralized tradeoffs • List of common wins, loses, and draws • In industry, tradeoff studies often try to justify things based on the “draws” instead of the “wins” 2Example System – Elevator Hall Call Button  Up Button • Button press  Up Button Light • Light on • Light off  Down Button • Button press  Down Button Light • Light on • Light off 3Elevator Call Button: Event-Based Messages  Button Press • Turn on button light • Send a “button pressed” message every time the button is pressed • Keep button light turned on for 500 msec after button pressed – Then turn button light off unless an acknowledgement message is received • Turn button light off when told to by hallway computer  Hallway computer (one for all floors) • When button is pressed, send acknowledgement to keep light on • When button is pressed, notify dispatching computer to send elevator car • When car doors open, send “turn button light off” message  For dependable systems, need handshake messages at every step • Might be at application layer • Might be at network protocol layer 4Elevator Call Button: Time-Triggered Messages  Send “button” and “button light” messages every 150 msec • Each message has current state of “on” or “off”  Button Press • Set “button state” variable to “pressed” (gets copied to hallway computer) • Turn on button light and force on for 500 msec; then follow message value • Whenever you can, check the button light state and set light accordingly (perhaps every 150 msec)  Hallway computer (one for all floors) • While button is pressed, notify dispatching computer to send elevator car – Set button light state to “on” • When car doors open, set button light state to “off” & button state to “off”  Message acknowledgements often not required • Missed button light state messages are self-correcting • User must correct a completely missed “button press” message by pressing again 5Tradeoff: When Do You Send A Message?  Event-based messages (“events”) • Send messages in response to an event – Similar to event-triggered systems – Think “asynchronous” state machine transitions • Can have high message frequency with an “event shower”  Time-Triggered messages (“state variables”) • Message sending is invisible to application programmer – Send messages periodically with the latest information – Think “synchronous” state machine transitions – “Looks” like a very small piece of shared memory • Reduces problems with missed messages • Matches communication & computing load to system control loop speeds rather than external environment • Have to infer that an event happened based on observing a value change – Might be easy to miss a sequence of quick events 6Generic Event-Triggered Approach  Sensors feed computers • But their values arrive asynchronously – whenever values are available • So, sensor values must be queued  Computers are demand driven • They process values from queues when available • Network messages are queued for transmission  Network is demand driven • Transmission queues release messages according to some network protocol  Actuators are demand driven • Actuator outputs occur in response to event messages 7Problem – Coordinating Events  Car example: transmission unlocks to shift out of park if: • Engine is running AND • Parking brake is OFF AND •Brake is ON  But, this is too simplistic • There are many arrival orders 8Asynchronous State Machine Problem  Asynchronous state machines have trouble with complex condition • Need to use states to keep track of which events have been seen if order is flexible • (This is also a problem with UML sequence diagrams)  Other models are possible that work around this • Colored Petri nets handle this situation better • But they can have problems with interrupts and asynchronous events 9Generic Time-Triggered Approach  Computers poll sensors • Sensors queried periodically • Sampled whether or not there has been a change  Computers are time triggered • Sensors are sampled when it is time perform a computation • State variables are placed in buffers for later transmission on network  Network is periodic • Copies of buffers are sent to all nodes periodically • Receiving nodes store most recent values, even if previous value unused • Remember the “blackboard architecture?” The receive buffers are that node’s locally stored copy of the current blackboard contents  Actuators are periodically driven • Actuators outputs asserted periodically regardless of change/no change 10Time Triggering Simplifies Event Coordination  Example: transmission unlocks to shift out of park if: • Engine is running AND • Parking brake is OFF AND •Brake is ON ENGINE ON ENGINE OFF & BRAKE ON BRAKE OFF & PB OFF PB ON 11General Time Triggered Design Notes  Design based on periodically updated state variables • Every compute/communication block has a state variable buffer • Buffer contents are updated whenever source sends an update • Buffer values are read whenever consuming functional block needs them • Generally, each value is updated atomically, but related values might not be updated together (so they might be out of synch by a cycle) 12Design Difference: Event vs. Time Triggered  Event triggered: • State machine only changes states when event occurs – Actions within state are executed exactly once, when state is entered • Each arc can have ONLY ONE incoming event/message – Instantaneous state changes – Events arrive via network message or are serialized in some other way – Requirements statements can depend on exactly ONE message (and possibly state variables specifically managed by the object) • In many cases these are simpler to understand & design – But, they are easily confused by dropped, duplicated, or out-of-order messages – Coordinating multiple messages requires messy temporary variables  Time triggered: • State machine changes periodically based on variables and most recent inputs – State machine has to infer events by noting state changes – Can change state based on multiple messages and/or local variable values – Actions within each state are executed continually • Tend to be more robust to dropped or out-of-order messages 13Mindless Formula for TT Behavioral Requirements  Time-triggered system: • ID (Null or message value, … message value) and (Null or variable value test, … variable value test) shall result in message transmitted, … variable value assigned, … • Can trigger on zero or more messages; zero or more variables – OK for left hand side trigger to ONLY be a state variable (or always be true) – Right hand side can have zero or more messages; zero or more variable values – “Shall” or “should” are both acceptable • OK to transmit multiple messages; OK to assign multiple variables • EVERY VERB GETS A NUMBER 14Questions on TT vs. ET?Distributed Computing – Step By Step Evolution Let’s work through how systems evolve from electromechanical to distributed STEP 1 – no computer at all  You don’t need a computer at all to operate light bulbs with switches  Non-computer control is possible • RLC circuits, analog transistors, etc. POWER A SOURCE A A S CONTROLS A 16Why Add A Computer?  Permits optimization • Using a many-to-many relationship for actuators to control sensors requires relays or other signal isolation (isolation relays would also be “computation” ) • Can change control loop behavior depending on system operating modes  Enables adding sophisticated features in software • Safety interlocks – Require brake pedal to be depressed before shifting into gear • Active safety operations – Car locks doors once shifted into gear • Timers, counters, conditional logic – Variable interval wipers that adapt to rain intensity  Enables context-sensitive operation • Switches can be momentary closure “soft switches” • Permits controller to set value even when switch isn’t pressed – Example: rear view window heaters off after timeout or if outside temp is hot 17Centralized System  Central computer • Reads input sensors • Provides motive power to actuators • Common ground (e.g., metal vehicle frame) used as electrical return path Wire Bundle POWER A SOURCE A CENTRAL A COMPUTER Wire Bundle S S Wire Bundle A S 18http://www.baesystems.com/gallery/air/images/FADEC_Full_Authority_Digital_Engine_Control_Testinghires.jpg 19http://www.bigcee.com/faq/KLR650-color-wiring-diagram.jpg 20