Sea Buoy Problem CMU-SEI Example Software Architecture Problem J. - PowerPoint PPT Presentation

Sea Buoy Problem CMU-SEI Example Software Architecture Problem J. Scott Hawker/R. Kuehl p. 1 R I T Software Engineering

Functional Requirements  Sea Buoy – a collection of untethered buoys acquire and maintain navigation and weather data, and provide the data to air and sea traffic  Use cases:  Collect environment data:  Air and water temperature every 10 seconds  Wind speed every 30 seconds  Location data every 10 seconds  Broadcast environment data  Every 60 seconds to air and sea traffic  On-demand broadcast 24-hour history  Activate/deactivate emergency SOS signal  Activate/deactivate red light, audio horn, and continuous broadcast of location data J. Scott Hawker/R. Kuehl p. 2 R I T Software Engineering

Architecturally Significant Requirements  Single processor due to cost  Must operate for one year without maintenance  Support multiple sensors and accommodation for future sensor types  Data formats depend on the sensors used  Availability requirement – 24/7  On-demand broadcasts have priority over periodic broadcasts  Emergency broadcasts have priority over all other broadcasts  There is limited memory to save raw data beyond one month but summary statistical data must be persisted J. Scott Hawker/R. Kuehl p. 3 R I T Software Engineering

First Order Software Architecture Design How Did We get Here? J. Scott Hawker/R. Kuehl p. 4 R I T Software Engineering

Design Patterns and Tactics  Synchronization - mutually exclusive access to data repositories  Concurrent Pipelines - several real-time information pipelines  Abstract Data Repository - handle sensor data format changes or addition of new sensor data types  Simplex pattern- redundancy (same functions but not implementation) to achieve availability/reliability J. Scott Hawker/R. Kuehl p. 5 R I T Software Engineering

Synchronization ASRs Access to sensor data  Single processor on which multiple processes reside, each of which perform computations on their own input data stream (messages)  Each final output from the system must be produced within a specified time interval after the arrival of an input (message) and after all computations have been performed  So completely process each message with a specified bounded end-to end latency — a deadline  Contention for shared resources J. Scott Hawker/R. Kuehl p. 6 R I T Software Engineering

Synchronization Design  Application: store sensor data then retrieve for periodic or on-demand transmission  Stimuli: two or more periodic or sporadic input streams  Response: end-to-end, worst-case latency  Decisions: process relationships based on prioritization, scheduling, data-locking policy J. Scott Hawker/R. Kuehl p. 7 R I T Software Engineering

Add in Broadcast and Transmit Function  Apply concurrent pipeline tactic - broadcast + transmission pipeline  Broadcast has lower frequency than data acquisition, so assign it a lower priority  but Broadcast could block sensor access to DB  Effective priority of a pipeline is strongly related to the lowest priority process in the pipeline  If transmission process priority is lower than broadcast priority, it effectively lowers the priority of the entire pipeline J. Scott Hawker/R. Kuehl p. 8 R I T Software Engineering

Apply Concurrent Pipeline Tactic J. Scott Hawker/R. Kuehl p. 9 R I T Software Engineering

Add in History Function “On - demand, broadcast 24 hour history” Quantitative analysis: what scheduling policy?  History request is stochastic (event-driven, aperiodic)  Data base synchronization and concurrent pipeline behavior is (assumed) deterministic  Non blocking data base access, priority based preemptive task scheduling  Apply rate monotonic scheduling (RMS)  Static priority scheduling - the shorter the task duration, the higher the task's priority  (versus round robin or time sharing for example) J. Scott Hawker/R. Kuehl p. 10 R I T Software Engineering

Add in SOS Function Analysis:  Constraint: SOS, history and broadcast all use the transmission process  SOS highest priority, then history, then broadcast  Synchronization treated transmit as a critical section, thus a long history broadcast could block a high priority SOS  Must make history broadcast preemptive  e.g. transmit long message in small chunks, preempt between chunks J. Scott Hawker/R. Kuehl p. 11 R I T Software Engineering

Adding in Modifiability Requirements  Modifications: add new sensor types  Will new sensors produce data in same or different format?  Are new sensors added or substitutes for existing sensors?  Is a new environmental parameter being sensed?  Apply a data indirection pattern to hide sensor changes:  Abstract Data Repository  Publish/Subscribe  Considerations: data format conversion effect on process execution time, thus latency J. Scott Hawker/R. Kuehl p. 12 R I T Software Engineering

Current Architecture J. Scott Hawker/R. Kuehl p. 13 R I T Software Engineering

Adding Availability Simplex Pattern  SOS function is critical  Add redundancy that use different mechanisms  Provide a separate hardware unit for SOS transmit J. Scott Hawker/R. Kuehl p. 14 R I T Software Engineering