SWD 392 - Software

Architecture and
Design
 24
Real-Time Software
Architecture
Case Study
SWD391
PROBLEM
DESCRIPTION
• An AGV System has the following characteristics:
• A computer-based AGV can move along a track in the factory in a clockwise
direction, and start and stop at factory stations. The AGV has the following
characteristics:
1. A motor, which is commanded to Start Moving and Stop Moving. The
motor
sends Started and Stopped responses.
2. An arrival sensor to detect when the AGV has arrived at a station, e.g.,
arrived at station x. If this is the destination station, the AGV should stop. if
it is not the destination station, the AGV should continue moving past the
station.
3. A robot arm for loading and unloading a part onto and off of the AGV.
• The AGV system receives Move commands from an external Supervisory
System. It sends vehicle Acknowledgements (Acks) to the Supervisory
System
• indicating that is has started moving, passed a station, or stopped at a
station. The AGV system also sends vehicle status to an external Display
System every 30 seconds.
• It is given that the arrival sensor is an event-driven input device and that the
motor and arm are passive I/O devices. It is also given that the AGV system
communicates with the Supervisory System and Display System by means of
messages.
USE CASE MODELING
• The use case model for the AGV System is depicted in
Figure 24.1. From the problem description, it can be
determined that there are two use cases, one dealing with
the vehicle moving to a station and the second dealing with
sending vehicle status to the display system.
• There are four actors: Supervisory System, Display System,
Arrival Sensor, and Clock.
• From the perspective of the AGV System, the Supervisory
System and Display System are external system actors.
• The Arrival Sensor is an input device actor, whereas the
Clock is a timer actor. The use case descriptions are given
next.
 2.1 Move to Station Use Case

• The Supervisory System is a primary actor that initiates the

Move to Station use case, because it sends the move
command to the AGV System.
• The Arrival Sensor is a secondary actor that participates in the
use case as it notifies the vehicle when it has reached a
station. The use case description is as follows:
 2.1 Move to Station Use Case

• Use case name: Move to Station

• Summary: The AGV moves a part to a factory station
• Actor: Supervisory System (primary), Arrival Sensor
(secondary)
• Precondition: The AGV is stationary.
 2.1 Move to Station Use Case
• Main sequence:
• 1. The Supervisory System sends a message to the AGV
system requesting it to move to a factory station and load a
part.
• 2. The AGV System commands the motor to start moving.
• 3. The motor notifies the AGV System that the vehicle has
started moving.
• 4. The AGV System sends a Departed message to the
Supervisory System. 474 Case Studies
• 5. The arrival sensor notifies the AGV System that it has
arrived at factory station (#).
 2.1 Move to Station Use Case

• 6. The AGV System determines that this station is the

destination station and commands the motor to stop moving.
• 7. The motor notifies the AGV System that the vehicle has
stopped
• moving.
• 8. The AGV System commands the robot arm to load the part.
• 9. The arm notifies the AGV System that the part has been
loaded.
• 10. The AGV System sends an Arrived message to the
Supervisory System.
 2.1 Move to Station Use Case

• Alternative sequences:
• Step 6: If the vehicle arrives at a different station from the
destination station, the vehicle passes the station without
stopping and sends a “Passed factory station (#) without
stopping” message to the Supervisory System.
• Steps 8, 9: If the Supervisory System requests the AGV to
move to a factory station and unload a part, the AGV will
unload the part after it arrives at the destination station.
• Postcondition: AGV has completed its mission and is at the
destination station
 2.2 Send Status Use Case

• The Clock is a primary actor, which initiates the Send Vehicle

Status use case, for which the Display System is a secondary
actor. The use case description is as follows:
• Use case name: Send Vehicle Status
• Summary: The AGV sends status information about its
location and idle/busy status to the display system.
• Actor: Clock (primary), Display System (secondary)
• Precondition: The AGV is operational.
 2.2 Send Status Use Case

• Main sequence:
1. Clock notifies AGV System that the timer has expired.
2. AGV System reads the status information about AGV
location and idle/busy status.
3. AGV System sends the AGV status information to the
Display System.
• Postcondition: AGV system has sent status information
STATIC MODELING
• This section describes the static model, which consists of the
system context model and the entity class model.
 3.1 Conceptual Static Modeling

• The conceptual static model is shown in Figure 24.2 using a

class diagram. It depicts a system of systems, consisting of
the Supervisory System, the AGV System, and the Display
System.
• The AGV System is modeled as a composite class, which
receives commands from and sends acknowledgments to
the Supervisory System, and sends status to the Display
System.
• The AGV System is composed of four classes: the Arrival
Sensor, the Motor, the Robot Arm, and the Clock.
 3.2 Software System Context Modeling

• The software system context diagram (Figure 24.3) is modeled

from the perspective of the software system to be developed,
the AGV System.
• It therefore depicts two external system classes (the
Supervisory System and the Display System) and the Clock
external timer class, which were originally depicted as actors
in the use case model.
3.2 Software System Context Modeling
3.2 Software System Context Modeling
OBJECT AND CLASS
STRUCTURING
• Object structuring for the AGV System is depicted in Figure
24.4. For each external class on the software system context
diagram, there is a corresponding internal software class.
• Thus, there are two proxy classes, Supervisory System Proxy
and Display Proxy, which communicate with the two external
systems, Supervisory System and Display System,
respectively.
• There is one input class, Arrival Sensor Interface, which
communicates with the Arrival Sensor external input device,
and two output classes, Motor Interface and Arm Interface,
which communicate with the Motor and Arm external output
devices, respectively.
• There are two additional classes, a state dependent control
class, Vehicle Control, which executes the vehicle state
machine, and an entity class, Vehicle Status, which contains
data about the vehicle destination and command.
• In addition, there is one timer class, Vehicle Timer.
DYNAMIC STATE
MACHINE MODELING
• Vehicle Control executes the vehicle state machine, which is
depicted on the state chart in Figure 24.5. The state machine
follows the states of the vehicle as it transitions from idle state
to moving, arriving at destination, loading or unloading the
part, and then restarting.
• The states are determined by following the main sequence
textually described in the Move to Station use case, and are as
follows:
• Idle. This is the initial state, in which the AGV is idle, waiting
for a command from the Supervisory System.
• Starting. This state is entered when the AGV has received a
Move to Station message from the Supervisory System and
has sent a start command to the motor.
• Moving. The AGV is moving to the next station.
• Checking Destination. The AGV has arrived at a station and is
checking to
determine whether this is its destination.
• Stopping to Load. This station is the destination, and the AGV
is to load a part. The AGV commands the motor to stop on
entry to this state.
• Part Loading. This robot arm is loading the part onto the AGV.
• Stopping to Unload. This station is the destination, and the
AGV is to unload a part. The AGV commands the motor to stop
on entry to this state.
• Part Unloading. This robot arm is unloading the part off the
AGV.
• Note that the Stopping to Load and the Stopping to Unload
states are kept separate because the actions leaving these
states are different (Load and Unload, respectively).
DYNAMIC INTERACTION
MODELING
• For each use case, a communication diagram is developed
that depicts the objects that participate in the use case and
the sequence of messages passed between them.
• Several objects realize the main use case, Move to Station;
however, only three software objects are needed to realize
the supporting use case, Send Vehicle Status.
6.1 Dynamic Modeling for Move to Station
• In the communication diagram for the Move to Station use
case (Figure 24.6), the sequence of external inputs and
external outputs on the communication diagram corresponds
to the sequence described in the use case and starts with the
command sent by the Supervisory System, which is the
primary actor.
• The objects that realize this use case are Supervisory System
Proxy, which receives the inputs from the Supervisory System;
Vehicle Control, which controls the objects that participate in
the use case; Vehicle Status, for storing and retrieving
destination location information;
6.1 Dynamic Modeling for Move to Station

• Arm Interface and Motor Interface, for interfacing to the two

external output devices; and Arrival Sensor Interface, for
receiving input from the arrival sensor.
• The message sequence description is as follows for a scenario
in which the vehicle goes past the first station and stops at
the second station to load a part
6.1 Dynamic Modeling for Move to Station
6.2 Dynamic Modeling for Send Vehicle
Status
• The communication diagram for the Send Vehicle Status
use case is shown in Figure 24.8. The objects that realize
this use case are the Vehicle Timer, which receives clock
inputs, Vehicle Status, which stores status information,
and Display Proxy, which sends vehicle status to the
external Display System.
• The message sequence starts with the external timer
event from the external Clock and the message
numbering is as follows:
6.2 Dynamic Modeling for Send Vehicle
Status

• 1: Clock sends Timer Event to Vehicle Timer.

• 1.1, 1.2: Vehicle Timer reads Vehicle Status.
• 1.3: Vehicle Timer sends Update Status message to
Display Proxy.
• 1.4: Display Proxy sends Vehicle Status to external
Display System
DESIGN MODELING
• The software architecture of the AGV System is designed
around a centralized control pattern.
• Centralized control is provided by the Vehicle Control
component Real-Time Software Architecture Case Study
483 receiving inputs from the Supervisory System and the
Arrival Sensor, and controlling the external environment by
means of the Motor and Arm.
• When viewed from the larger perspective of a factory
automation system, the architecture is a based around a
hierarchical control pattern,
• with several instances of the AGV System(each instance
controlling an individual vehicle) operating under the
overall direction of a Supervisory System,
• which provides hierarchical control of the individual
AGVs by sending move commands to each vehicle.
7.1 Integrated Communication Diagram
• The initial attempt at design modeling involves developing
the integrated communication diagram for the AGV
System, which requires the integration of the two use
case–based communication diagrams shown in Figures
24.6 and 24.8.
• The integrated communication diagram is depicted in
Figure 24.9. The integration is quite straightforward,
because the only object that participates in both the use
case–based communication diagrams is Vehicle Status.
• The integrated communication diagram is a generic
communication diagram in that it depicts all possible
communications between the objects.
 7.2 Component-Based Software
•
Architecture
The distributed software architecture for the Factory
of Factory
Automation Automation
System, which is a system ofSystem
systems, is
shown on the system communication diagram in Figure
24.10.
• It depicts the three interacting distributed systems
(designed as components): the Supervisory System, the
Automated Guided Vehicle (AGV) System, and the Display
System.
• There is one instance of the Supervisory System, and
multiple instances of the AGV System and the Display
System. All communication between the distributed
components is asynchronous, which allows the greatest
flexibility in message communication.
• Communication between the Supervisory System and the
AGV System is an example of bidirectional asynchronous
7.3 Software Architecture of Automatic
Guided
Vehicle System
• The AGV System is designed as a real-time component-
based software architecture.
• A component-based design provides the advantages of a
configurable design and follows the concepts described in
Chapter 17.
• The real-time design is needed because of the
characteristics of the application, and it follows the
concurrent task structuring criteria and message-based
task interface design described in Chapter 18.
7.3 Software Architecture of Automatic
Guided
Vehicle System
• The design of the AGV System is based on the centralized
control pattern for real-time designs (see Chapter 18).
• One control component, Vehicle Control, provides the
overall control of the system.
• In addition, the AGV System is designed as a distributed
component-based software architecture, which allows the
option for input and output components to reside on
separate nodes that are connected by a high-speed bus.
• At system deployment time, the type of configuration
required – centralized or distributed – is determined.
7.3 Software Architecture of Automatic
Guided
Vehicle System
7.3 Software Architecture of Automatic
Guided
Vehicle System
• The concurrent software architecture for the AGV System is
developed from the integrated communication diagram by
applying the task structuring criteria to design the
concurrent tasks and architectural communication patterns
to design the message communication between tasks.
• Next the component-based architecture is designed.
• Finally, the provided and required interfaces of each
component are described.
• Each component port is defined in terms of its provided
and/or required interfaces.
7.3 Software Architecture of Automatic
Guided
Vehicle System
7.4 Concurrent Software Architecture
• In this concurrent real-time design, the concurrent task
structuring criteria are applied to determine the tasks in
the Automatic Guided Vehicle System.
• The concurrent task design (see Figure 22.14) is developed
by starting from the integrated communication diagram in
Figure 24.9, which depicts all the objects in the AGV
System.
• All these objects are concurrent because they need to
operate independently, except Vehicle Status, which is a
passive data abstraction object.
• Because the goal is to design a concurrent component-
based software architecture, the tasks are all designed as
simple concurrent components, each with its own single
thread of control.
• Thus, in this design, the terms task and simple component
are synonymous. The concurrent tasks are described in
7.4 Concurrent Software Architecture

• Input tasks. Concurrent input tasks receive inputs from the

external environment and send corresponding messages
to the control task. Arrival Sensor Component (Figure
24.14) is designed as an event-driven input task, which is
awakened by the arrival of an arrival sensor input.
• The input task consists of the individual input device
interface object depicted in the analysis model (see Figure
24.9): Arrival Sensor Interface.
7.4 Concurrent Software Architecture
• Proxy tasks. Supervisory System Proxy acts on behalf of
the Supervisory System, from which it receives Move
commands that are forwarded to Vehicle Control, and it
sends AGV acknowledgements to Supervisory System.
• Supervisory System Proxy is designed as an event-driven
task, which is awakened by messages from either the
external Supervisory System or the internal Vehicle
Control.
• Note that if a task receives both external and internal
messages, it is categorized as an event driven task and
not a demand driven task. Display Proxy acts on behalf of
the Display System, to which it forwards AGV status
messages.
• Display Proxy is designed as a demand driven task,
awakened on demand by the arrival of a message from
7.4 Concurrent Software Architecture

• Control task. Vehicle Control is the centralized state

dependent control task for the AGV system.
• It executes the Vehicle Control state machine and receives
messages from other tasks that contain events, causing
Vehicle Control to change state and send action messages
to other tasks.
• Vehicle Control is designed as a demand driven task,
which is awakened by arrival of a message from either
Supervisory System Proxy or Arrival Sensor Component.
7.4 Concurrent Software Architecture

• Output tasks. The Arm Component interfaces to the

external Arm. The Arm Interface object from the analysis
model is mapped to this output task (see Figures 24.9 and
24.14).
• Similarly, the Motor Component interfaces to the external
Motor and is designed from the analysis model Motor
Interface object.
• Both of the output tasks are designed as demand driven
tasks, which are awakened on demand by arrival of a
message from Vehicle Control.
7.5 Architectural Communication Patterns

• The actual type of message communication – synchronous

or asynchronous – still needs to be determined.
• To handle the variety of communication between the tasks
in the AGV System, four communication patterns are
applied:
7.5 Architectural Communication Patterns

• The actual type of message communication – synchronous

or asynchronous – still needs to be determined.
• To handle the variety of communication between the tasks
in the AGV System, four communication patterns are
applied:
7.5 Architectural Communication Patterns

• Asynchronous Message Communication. The

Asynchronous Message Communication pattern is widely
used in the AGV System because most communication is
one-way, and this pattern has the advantage of not letting
the consumers hold up the producers.
• The Vehicle Control task needs to be able to receive
messages from either of its two producers, Supervisory
System Proxy and Arrival Sensor Component, in any order.
7.5 Architectural Communication Patterns

• The best way to handle this requirement for flexibility is

through asynchronous message communication, with one
input message queue for the Vehicle Control task, so that
Vehicle Control will receive whichever message arrives
first, move command or station arrival.
• The Vehicle Timer task sends asynchronous AGV status
messages to the Display Proxy task, which receives these
messages on a message queue.
7.5 Architectural Communication Patterns

• Bidirectional Asynchronous Communication. This

communication pattern is used between the Supervisory
System Proxy and Vehicle Control,
• because considerable time could elapse between
Supervisory System Proxy sending the move command to
Vehicle Control and Vehicle Control sending the
acknowledge response to the Supervisory System Proxy
(after the AGV has arrived at its destination).
• Thus, move and acknowledge messages are decoupled.
7.5 Architectural Communication Patterns

• Synchronous Message Communication without Reply. This

pattern is used when the producer needs to make sure
that the consumer has accepted the message before the
producer continues.
• This pattern is used between the Vehicle Control and Arm
Component, as well as between Vehicle Control and Motor
Component.
• In both cases, the consumer task is idle until it accepts the
message, so the Vehicle Control producer is not held up
after sending the message.
7.5 Architectural Communication Patterns

• Call/Return. This pattern is used when AGV Control and

Vehicle Timer
• invoke the operations of the passive Vehicle Status (see
Figure 24.14) data abstraction object.
 7.6 Component-Based Software
Architecture

• The Automated Guided Vehicle System component is

designed as a composite component that contains eight
simple part components; seven of these are concurrent
components (Supervisory System Proxy, Arrival Sensor
Component, Vehicle Control, Vehicle Timer, Arm
Component, Motor Component, and Display Proxy), and
the other is a passive data abstraction object (Vehicle
Status).
 7.7 Design of Component Interfaces
• Each component port is defined in terms of its provided
and/or required interfaces.
• Some producer components – in particular, the input
component – do not provide a software interface, because
they receive their inputs directly from the external
hardware input device.
• However, they require an interface provided by the control
component in order to send messages to the control
component.
• Figure 24.16 depicts the port and required interface for the
input component Arrival Sensor Component.
• This input component, as well as the Supervisory System
Proxy component, has the same required interface –
IAGVControl, which is provided by the Vehicle Control
component.
7.7 Design of Component Interfaces
 7.7 Design of Component Interfaces

• The output components do not require a software interface

because their outputs go directly to external hardware
output devices.
• However, they need to provide an interface to receive
messages sent by the control component.
• Figure 24.16 depicts the ports and provided interfaces for
the two output components of the AGV System.
 7.7 Design of Component Interfaces

• Figure 24.17 also shows the specifications of the interfaces

in terms of the operations they provide. The Arm
Component and Motor Component output components
each have a provided port:
• PArm for Arm Component, which provides the interface
IArm
• PMotor for Motor Component, which provides the
interface IMotor
• The Display Proxy component has a provided port called
PDisplay, which in turn provides an interface called
IDisplay, as shown in Figure 24.16. Figure 24.17 shows the
specification of the interface.
 7.7 Design of Component Interfaces
• Some components, such as control components, need to
provide interfaces for the producer components to use and
require interfaces that are provided by output
components.
• The Vehicle Control component has several ports – one
provided port and three required ports – as shown in Figure
24.16.
• Each required port is used to interface to a different
consumer component and is given the prefix R – for
example, RArm.
• The provided port, which is called PAGVControl, provides
the interface IAGVControl, which is required by the
producer components.
7.7 Design of Component Interfaces
 7.7 Design of Component Interfaces

• Figure 24.17. It is kept simple by having only one

operation, processControlRequest, which has an input
parameter, controlRequest, that holds the name and
contents of the individual message.
• Having each control request as a separate operation would
make the interface more complicated when considering
evolution of the system because it would need the
addition or deletion of operations rather than changing a
parameter.
 7.7 Design of Component Interfaces

• The ports and interfaces of the periodic timer component

are shown in Figures 24.16 and 24.17. The Vehicle Timer
has two required ports with two required interfaces.
• The first required interface is IAGVStatus, which allows it
to read AGV status information from the Vehicle Status
data abstraction object.
• The second required interface is IDisplay, which allows
Vehicle Timer to send AGV status messages to Display
Proxy
7.7 Design of Component Interfaces
 7.7 Design of Component Interfaces
• The update operation stores the next AGV destination and
the command to be executed there (load or unload).
• The check operation receives the current station number
and returns whether this is the destination or not; if it is
the destination, it also returns whether the station
command is load or unload.
• The read operation returns the location, destination, and
load/unload command.
• The attributes of the Vehicle Status data abstraction class
are given in Figure 24.18.
• This figure also depicts the state machine class design for
Vehicle State Machine, which is encapsulated inside the
Vehicle Control component.
Thanks!
CREDITS: This presentation template
was created by Slidesgo, including
icons by Flaticon, infographics &
images by Freepik