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

• J. Scott Hawker/R. Kuehl
• p. 1

R I T

Software Engineering

Sea Buoy Problem

CMU-SEI Example Software Architecture Problem

• J. Scott Hawker/R. Kuehl
• p. 2

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. 3

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. 4

R I T

Software Engineering

First Order Software Architecture Design How Did We get Here?

• J. Scott Hawker/R. Kuehl
• p. 5

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. 6

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. 7

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. 8

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. 9

R I T

Software Engineering

Apply Concurrent Pipeline Tactic

• J. Scott Hawker/R. Kuehl
• p. 10

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. 11

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. 12

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

• n process execution time, thus latency

• J. Scott Hawker/R. Kuehl
• p. 13

R I T

Software Engineering

Current Architecture

• J. Scott Hawker/R. Kuehl
• p. 14

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