Mouse Droid
Mouse Droid mouse-droid CFUListDiagram D0001
This document shows a system architecture
and software architecture for a mouse droid.
This is a small repair droid similar to the MSE-6 used on death star 1.
The document follows the arc42.org template
proposed by Gernot Starke and Peter Hruschka,
Copyright 2020-2023 Andreas Warnke
License:
Choose either Apache-2.0
or Creative Commons Attribution (BY) Licence
Introduction mouse-droid Comment C0001
The mouse droid is a repair droid.
When programmed,
it autonomously drives to the destination location,
selects spare parts and tools
and exchanges damaged parts.
It is easily reprogrammable and can therefore also be used for
- cleaning tasks
- spying and surveillance tasks
- message delivery
Scope Comment C0141
This document describes system and software architecture for engineering generation 5 of the mouse droid, denoted by the term MoD5G.
mouse-droid Image C0173
Requirements and Goals
Requirements and Goals mouse-droid UMLUseCaseDiagram D0002
This section gives a short overview on the project goals (Problem Space, System Level L1)
Primary purpose of the MoD5G is to autonomously repair mechanical things.
Requirements and Goals, Requirements and Goals, Scope and Context, Deployment View
Mouse Droid MoD5G mouse-droid Component C0004
The Mouse Droid (MoD5G) is a repair droid that can be instructed to perform a mission and which then autonomously selects tactics to achieve the mission goals.
+-- Perform a 1-day mission Association R0001
+-- Return to base location Association R0283
+-- Drive to location Association R0003
+-- Repair using tools Association R0004
Commander Actor C0005
The commander instructs the MoD5G on the mission to perform.
plan mission --> Perform a 1-day mission Association R0002
provide mission goals and high-level strategy
Perform a 1-day mission goal UseCase C0006
The mouse droid is able to perform a mission that takes several hours. The energy resources of the MoD5G last for up to one terrestrial day.
- The commander programs a mission
- The mouse droid drives to the first location
- The mouse droid uses tools to remove a defective part
- The mouse droid installes a spare part
- Above steps are repeated for other goals
- The mouse droid returns to its base location (see Glossary)
post: MoD5G is at base location Property F0034
1.) ··> Drive to location Include R0005
2.) ··> Repair using tools Include R0006
3.) ··> Return to base location Include R0284
Requirements and Goals, L1 Requirements View, Requirements and Goals
Drive to location goal UseCase C0007
The mouse droid can explore its environment and calculate a route from its actual position to the target location.
- The mouse droid explores its environment
- The mouse droid enriches an internally memorized map
- The mouse droid calculates a route
- The mouse droid drives along the calculated route
- The mouse droid re-caclulates the route in case of new environment data
- The mouse droid reaches the target location
pre: defined mission Property F0032
Requirements and Goals, L1 Requirements View, Requirements and Goals
Repair using tools goal UseCase C0008
The mouse droid has a couple of tools inside its chassis.
- The mouse droid uses a screw diver to untighten damaged parts
- The mouse droid uses a gripper to move the damaged part out of the way
- The mouse droid uses a gripper to put a spare part from its internal cargo bin to the target place
- The mouse droid uses a screw diver to tighten replaced parts
- The mouse droid uses a gripper to move the damaged part into its internal cargo bin.
(see L2 Mechanics)
L1 Requirements View, Requirements and Goals
Return to base location goal UseCase C0177
see Glossary.
post: MoD5G is at base location Property F0033
L1 Requirements View
L1 Requirements View SysMLRequirementDiagram D0044
This diagram shows examples of system level L1 requirements.
Requirements and Goals, L1 Requirements View, Requirements and Goals
Drive to location goal UseCase C0007
The mouse droid can explore its environment and calculate a route from its actual position to the target location.
- The mouse droid explores its environment
- The mouse droid enriches an internally memorized map
- The mouse droid calculates a route
- The mouse droid drives along the calculated route
- The mouse droid re-caclulates the route in case of new environment data
- The mouse droid reaches the target location
pre: defined mission Property F0032
Requirements and Goals, L1 Requirements View, Requirements and Goals
Repair using tools goal UseCase C0008
The mouse droid has a couple of tools inside its chassis.
- The mouse droid uses a screw diver to untighten damaged parts
- The mouse droid uses a gripper to move the damaged part out of the way
- The mouse droid uses a gripper to put a spare part from its internal cargo bin to the target place
- The mouse droid uses a screw diver to tighten replaced parts
- The mouse droid uses a gripper to move the damaged part into its internal cargo bin.
(see L2 Mechanics)
L1 Requirements View, L3 Requirements
L1Req: Recognize paths env-perception Requirement C0149
The MoDG5 shall use redundant sensor data to calculate paths that it can drive along.
··> Drive to location Trace R0244
··> Return to base location Trace R0285
L1 Requirements View, L3 Requirements
L1Req: Position screw driver Requirement C0150
The MoDG5 shall bring the screw driver into a given 3D position.
··> Repair using tools Trace R0245
L1 Requirements View, Requirements and Goals
Return to base location goal UseCase C0177
see Glossary.
post: MoD5G is at base location Property F0033
Constraints
Constraints SysMLRequirementDiagram D0003
This section explains the major obstacles that need to be considered when designing a solution that addresses the project goals. (Problem Space, System Level L1)
Operating Temperatures environment Requirement C0003
The droid shall be fully functional in the range 240K..360K, it shall survive temperatures from 200K to 400K.
Constraints, Architecture Decisions
Cosmic Rays environment Requirement C0002
The droid shall ensure data and program integrity.
It shall continue operation after cosmic rays have interfered with data storage or program execution.
Corrupted data must not be stored permanently.
Environmental Constraints environment Package C0144
This package lists technical/physical constraints imposed by the environment in which to operate.
+-- Cosmic Rays Association R0221
+-- Operating Temperatures Association R0222
Group of constratins imposed by the operation environment
Scope and Context
Scope and Context UMLUseCaseDiagram D0004
This section shows the organizational contexts of development and operational environments. (Problem Space, System Level L1)
Development and Production Context Component C0088
This boundary encompasses the topics that are in scope during development and production.
+-- Electrical Engineering Association R0188
+-- Design Hardware Association R0187
+-- Develop Software Association R0125
+-- Build Droids Association R0124
Operational Context Component C0089
This boundary encompasses the topics that are in scope during operation and maintenance.
+-- Repair Droid Association R0127
+-- Operate Droid Association R0126
Build Droids factory UseCase C0090
At the factory, workers assemble hardware and electronic parts to mouse droids and integrate control logic and data.
Develop Software sw_engineering UseCase C0091
A team of engineers designs, produces and tests the control logic and factory data of the droids.
Operate Droid usage UseCase C0092
An operator/commander instructs the mouse droid which mission to perform. The logic of the mouse droid translates this mission into driving maneuvers and actions of the integrated tools.
Repair Droid maintenance UseCase C0093
A service mechanic analyzes the health state of a mouse droid. Depending on the outcome, oil is refilled, logic is updated, parts are exchanged or the whole droid is disintegrated.
Design Hardware hw_design UseCase C0135
A team of engineers designs, produces and tests the mechanical hardware parts of the droids.
Electrical Engineering electronics_design UseCase C0136
A team of engineers designs, produces and tests the electrical and electronic parts of the droids.
Solution Strategy
Solution Strategy UMLComponentDiagram D0005
This section shows the fundamental base principle of the system design. (Solution Space, System Level L1)
L2 Mechanics, L1 Physical View, Solution Strategy, Building Block View, L2 Electric Parts and Electronics
Electrical Parts and Electronics HW Block C0019
The main components of the electric parts are:
- a set of cables and connectors
- a set of sensors and actuators
- the energy cell
- two printed circuit boards (PCB) containing the electronic parts
+-- Base Logic Board Association R0048
+-- Main Logic Board Association R0047
Base Logic Board, L3 Requirements, L1 Physical View, Solution Strategy, L2 Electric Parts and Electronics
Base Logic Board Block C0048
The base logic board consists of several electronic parts shown in Base Logic Board.
Main Board Connector Port F0031
Main Board Logic, L3 Requirements, L1 Physical View, Solution Strategy, L2 Electric Parts and Electronics
Main Logic Board Block C0047
The main logic board consists of several electronic parts shown in Main Board Logic.
Base Board Connector Port F0008
Mic-Connector I2S Port F0002
Camera LVDS Port F0001
status and control -- Base Logic Board CommunicationPath R0280
Outer World env-perception Comment C0094
The main logic
addresses the following tasks:
- evaluating sensor signals
from microphone and camera
- calculating movement actions
to be performed by base logic (tactics)
··> Main Logic Board Dependency R0184
Guiding Main Principles mouse-droid Comment C0116
The functions of the MoD5G are divided
onto two logic boards.
The base logic
gets local sensor information
and controls things within
the system boundary of the MoD5G.
The main logic
gets sensor data of the environment
and calculates movement actions
to efficiently fulfill the mission
(that was programmed before).
Inner World Comment C0117
The base logic addresses the following tasks:
- charging
- programming
- steering the motors
- self-check
If a list of actions is available,
this logic board can steer the MoD6G
without the help of the main logic board.
··> Base Logic Board Dependency R0183
L1 Functional View
L1 Functional View SysMLBlockDefinitionDiagram D0050
-- Plan movement strategy (L1-Fct) CommunicationPath R0286
-- Plan repair strategy (L1-Fct) CommunicationPath R0287
L1 Functional View, L1 Logical View
Plan movement strategy (L1-Fct) role Block C0181
paths Port F0036
-- Perform movement tactic (L1-Fct) CommunicationPath R0288
L1 Functional View, L1 Logical View
Plan repair strategy (L1-Fct) role Block C0182
objects Port F0038
-- Perform repair tactic (L1-Fct) CommunicationPath R0289
L1 Functional View, L1 Logical View
Perform movement tactic (L1-Fct) role Block C0183
ctrl Port F0042
-- Motors to move the MoD5G (L1-Fct) CommunicationPath R0290
-- Tools to repair CommunicationPath R0291
L1 Logical View
L1 Logical View SysMLBlockDefinitionDiagram D0051
This view maps the functions to a form.
L1 Functional View, L1 Logical View
Plan movement strategy (L1-Fct) role Block C0181
paths Port F0036
-- Perform movement tactic (L1-Fct) CommunicationPath R0288
L1 Functional View, L1 Logical View
Plan repair strategy (L1-Fct) role Block C0182
objects Port F0038
-- Perform repair tactic (L1-Fct) CommunicationPath R0289
L1 Functional View, L1 Logical View
Perform movement tactic (L1-Fct) role Block C0183
ctrl Port F0042
L1 Logical View, L1 Physical View
Strategy planning (L1) Block C0186
+-- Plan movement strategy (L1-Fct) Association R0292
+-- Plan repair strategy (L1-Fct) Association R0293
L1 Logical View, L1 Physical View
Tactic execution (L1) Block C0187
+-- Perform movement tactic (L1-Fct) Association R0294
+-- Perform repair tactic (L1-Fct) Association R0295
L1 Physical View
L1 Physical View SysMLBlockDefinitionDiagram D0052
This view maps the logical form to physical artifacts.
L2 Mechanics, L1 Physical View, Solution Strategy, Building Block View, L2 Electric Parts and Electronics
Electrical Parts and Electronics HW Block C0019
The main components of the electric parts are:
- a set of cables and connectors
- a set of sensors and actuators
- the energy cell
- two printed circuit boards (PCB) containing the electronic parts
+-- Base Logic Board Association R0048
+-- Main Logic Board Association R0047
Base Logic Board, L3 Requirements, L1 Physical View, Solution Strategy, L2 Electric Parts and Electronics
Base Logic Board Block C0048
The base logic board consists of several electronic parts shown in Base Logic Board.
Main Board Connector Port F0031
+-- Tactic execution (L1) Association R0297
Main Board Logic, L3 Requirements, L1 Physical View, Solution Strategy, L2 Electric Parts and Electronics
Main Logic Board Block C0047
The main logic board consists of several electronic parts shown in Main Board Logic.
Base Board Connector Port F0008
Mic-Connector I2S Port F0002
Camera LVDS Port F0001
status and control -- Base Logic Board CommunicationPath R0280
+-- Strategy planning (L1) Association R0296
L1 Logical View, L1 Physical View
Tactic execution (L1) Block C0187
L1 Logical View, L1 Physical View
Strategy planning (L1) Block C0186
Building Block View
Building Block View SysMLBlockDefinitionDiagram D0006
This section shows the parts of the MoD5G system (Solution Space, System Level L1)
L2 Mechanics, Building Block View
Mechanical Parts HW Block C0018
The mechanical parts encompass all parts of which the mouse droid consists.
From outside, the chassis and wheels are the most obvious parts.
Inside, a skeleton frame provides stability of the assembly.
Important charactereistics are weight, operating temperature range, durability, stability.
+-- Electrical Parts and Electronics Association R0013
L2 Mechanics, L1 Physical View, Solution Strategy, Building Block View, L2 Electric Parts and Electronics
Electrical Parts and Electronics HW Block C0019
The main components of the electric parts are:
- a set of cables and connectors
- a set of sensors and actuators
- the energy cell
- two printed circuit boards (PCB) containing the electronic parts
Building Block View, Solution Strategy, Building Block View
Software Parts SW Package C0020
The software consists of control logic, initial data that was integrated at the factory and learned data that is aggregated during operation.
These software items are split over two logical boards and subdivided into independent execution partitions.
··> Electrical Parts and Electronics Deployment R0243
L2 Mechanics
L2 Mechanics UMLComponentDiagram D0014
This section shows the mechanical parts of the MoD5G system (Solution Space, System Level L2)
Chassis mouse-droid Block C0035
+-- Skeleton Frame Association R0228
+-- Tool-Window (2) Association R0065
+-- Gripper Association R0064
+-- Cargo Bin Association R0034
+-- Microphone Association R0040
+-- Energy Cell Association R0044
+-- Programming and Diagnostic Connector Association R0042
+-- Motors Association R0038
+-- Loud Speaker Association R0041
+-- Charging Connector Association R0043
+-- Camera Association R0039
+-- Wheels (4) Association R0036
+-- Fan Association R0037
+-- Screw Driver Association R0035
+-- Electrical Parts and Electronics Association R0046
Cargo Bin Block C0036
protected by ··> Tool-Window (2) Dependency R0224
Screw Driver Block C0037
protected by ··> Tool-Window (2) Dependency R0225
Wheels (4) Block C0038
L2 Mechanics, L2 Electric Parts and Electronics
Motors Block C0040
L2 Mechanics, L3 Requirements, L2 Electric Parts and Electronics
Camera env-perception Block C0041
L2 Mechanics, L2 Electric Parts and Electronics
Microphone env-perception Block C0042
L2 Mechanics, L2 Electric Parts and Electronics
Loud Speaker Block C0043
L2 Mechanics, L2 Electric Parts and Electronics
Programming and Diagnostic Connector Block C0044
protected by ··> Tool-Window (2) Dependency R0226
L2 Mechanics, L2 Electric Parts and Electronics
Charging Connector Block C0045
L2 Mechanics, L2 Electric Parts and Electronics
Energy Cell Block C0046
L2 Mechanics, Building Block View
Mechanical Parts HW Block C0018
The mechanical parts encompass all parts of which the mouse droid consists.
From outside, the chassis and wheels are the most obvious parts.
Inside, a skeleton frame provides stability of the assembly.
Important charactereistics are weight, operating temperature range, durability, stability.
+-- Electrical Parts and Electronics Association R0013
+-- Chassis Association R0045
L2 Mechanics, L1 Physical View, Solution Strategy, Building Block View, L2 Electric Parts and Electronics
Electrical Parts and Electronics HW Block C0019
The main components of the electric parts are:
- a set of cables and connectors
- a set of sensors and actuators
- the energy cell
- two printed circuit boards (PCB) containing the electronic parts
protected by ··> Tool-Window (2) Dependency R0223
Tool-Window (2) Block C0055
A tool window is a flap in the chassis that protects screw driver, gripper and cargo bin when unused. It can be opened and closed by a motor.
Skeleton Frame mouse-droid Block C0146
The skeleton frame provides stability to the assembly of parts. Anchorage points latch the assembled parts at their positions.
L2 Electric Parts and Electronics
L2 Electric Parts and Electronics SysMLBlockDefinitionDiagram D0018
This section shows the electric parts and electronics of the MoD5G system (Solution Space, System Level L2)
L2 Mechanics, L1 Physical View, Solution Strategy, Building Block View, L2 Electric Parts and Electronics
Electrical Parts and Electronics HW Block C0019
The main components of the electric parts are:
- a set of cables and connectors
- a set of sensors and actuators
- the energy cell
- two printed circuit boards (PCB) containing the electronic parts
+-- Base Logic Board Association R0048
+-- Main Logic Board Association R0047
L2 Mechanics, L2 Electric Parts and Electronics
Energy Cell Block C0046
power -- PMIC CommunicationPath R0050
L2 Mechanics, L2 Electric Parts and Electronics
Loud Speaker Block C0043
L2 Mechanics, L3 Requirements, L2 Electric Parts and Electronics
Camera env-perception Block C0041
-- Main Logic Board CommunicationPath R0051
L2 Mechanics, L2 Electric Parts and Electronics
Microphone env-perception Block C0042
audio -- Main Logic Board CommunicationPath R0056
L2 Mechanics, L2 Electric Parts and Electronics
Motors Block C0040
L2 Mechanics, L2 Electric Parts and Electronics
Charging Connector Block C0045
-- PMIC CommunicationPath R0057
L2 Mechanics, L2 Electric Parts and Electronics
Programming and Diagnostic Connector Block C0044
service ctrl -- Base Micro Controller CommunicationPath R0061
Main Board Logic, L3 Requirements, L1 Physical View, Solution Strategy, L2 Electric Parts and Electronics
Main Logic Board Block C0047
The main logic board consists of several electronic parts shown in Main Board Logic.
Base Board Connector Port F0008
Mic-Connector I2S Port F0002
Camera LVDS Port F0001
status and control -- Base Logic Board CommunicationPath R0280
Base Logic Board, L3 Requirements, L1 Physical View, Solution Strategy, L2 Electric Parts and Electronics
Base Logic Board Block C0048
The base logic board consists of several electronic parts shown in Base Logic Board.
Main Board Connector Port F0031
+-- Base Micro Controller Association R0053
+-- PMIC Association R0049
-- Base Micro Controller CommunicationPath R0279
Base Logic Board, L2 Electric Parts and Electronics
PMIC Block C0049
Power Management Integrated Circuit
power -- Main Logic Board CommunicationPath R0063
Base Logic Board, Requirements and Goals, L2 Electric Parts and Electronics, L2 Software [subsystem]
Base Micro Controller Block C0051
The base micro controller consists of
- logic unit
- data storage
- persistent data+logic storage
- self supervision (by ECC and lockstep-cores)
- HW watchdog
- clock
- temperature sensor
- io ports
This block is optimized for providing a reliable execution of algorithms, see Quality Requirements.
Temperature sensor Port F0010
clock comm I2C Port F0007
Main Board Connector Port F0009
Speaker I2S Port F0004
Motor Control I2C Port F0003
Diag JTAG Port F0005
reset cmd Port F0006
-- Motors CommunicationPath R0059
-- Loud Speaker CommunicationPath R0060
-- PMIC CommunicationPath R0062
Base Logic Board
Base Logic Board SysMLInternalBlockDiagram D0035
This section shows the base board logic of the MoD5G system (Solution Space, System Level L3)
Base Logic Board, L3 Requirements, L1 Physical View, Solution Strategy, L2 Electric Parts and Electronics
Base Logic Board Block C0048
The base logic board consists of several electronic parts shown in Base Logic Board.
Main Board Connector Port F0031
+-- Base Micro Controller Association R0053
+-- Clock Association R0055
+-- PMIC Association R0049
+-- Temperature Sensor Association R0095
-- Base Micro Controller CommunicationPath R0279
Base Logic Board, Requirements and Goals, L2 Electric Parts and Electronics, L2 Software [subsystem]
Base Micro Controller Block C0051
The base micro controller consists of
- logic unit
- data storage
- persistent data+logic storage
- self supervision (by ECC and lockstep-cores)
- HW watchdog
- clock
- temperature sensor
- io ports
This block is optimized for providing a reliable execution of algorithms, see Quality Requirements.
Temperature sensor Port F0010
clock comm I2C Port F0007
Main Board Connector Port F0009
Speaker I2S Port F0004
Motor Control I2C Port F0003
Diag JTAG Port F0005
reset cmd Port F0006
-- PMIC CommunicationPath R0062
-- Clock CommunicationPath R0066
Clock Block C0053
wakeup -- PMIC CommunicationPath R0067
Base Logic Board, L2 Electric Parts and Electronics
PMIC Block C0049
Power Management Integrated Circuit
Temperature Sensor Block C0071
-- Base Micro Controller CommunicationPath R0096
Main Board Logic
Main Board Logic SysMLInternalBlockDiagram D0022
This section shows the main board logic of the MoD5G system (Solution Space, System Level L3)
Main Board Logic, L3 Requirements, L1 Physical View, Solution Strategy, L2 Electric Parts and Electronics
Main Logic Board Block C0047
The main logic board consists of several electronic parts shown in Main Board Logic.
Base Board Connector Port F0008
Mic-Connector I2S Port F0002
Camera LVDS Port F0001
+-- RAM Association R0070
+-- ROM Association R0071
+-- High Performance SoC Association R0069
+-- Motivator Association R0077
-- High Performance SoC CommunicationPath R0074
-- High Performance SoC CommunicationPath R0076
Main Board Logic, Requirements and Goals, L2 Software [subsystem]
High Performance SoC Block C0056
This block provides an execution environment for algorithms that is optimized for high performance.
-- RAM CommunicationPath R0072
-- ROM CommunicationPath R0073
-- Main Logic Board CommunicationPath R0075
RAM Block C0057
ROM Block C0058
triggers -- High Performance SoC CommunicationPath R0078
L2 Software [subsystem]
L2 Software [subsystem] UMLDeploymentDiagram D0019
This diagram shows the virtual machines and specialized (non-versatile) execution environments (Solution Space, System Level L2)
These are deployed onto the logic boards shown in L2 Electric Parts and Electronics.
In this section, this view is further detailed to software elements, their relations and interactions.
Main Board Logic, Requirements and Goals, L2 Software [subsystem]
High Performance SoC Block C0056
This block provides an execution environment for algorithms that is optimized for high performance.
+-- Real Time Video Processing Chip Association R0079
+-- General Purpose Partition 1 Association R0081
+-- General Purpose Partition 2 Association R0082
Base Logic Board, Requirements and Goals, L2 Electric Parts and Electronics, L2 Software [subsystem]
Base Micro Controller Block C0051
The base micro controller consists of
- logic unit
- data storage
- persistent data+logic storage
- self supervision (by ECC and lockstep-cores)
- HW watchdog
- clock
- temperature sensor
- io ports
This block is optimized for providing a reliable execution of algorithms, see Quality Requirements.
Temperature sensor Port F0010
clock comm I2C Port F0007
Main Board Connector Port F0009
Speaker I2S Port F0004
Motor Control I2C Port F0003
Diag JTAG Port F0005
reset cmd Port F0006
+-- Base Logic SW Partition Association R0083
+-- Watchdog Execution Environment Association R0080
Deployment View, L2 Software [subsystem]
Real Time Video Processing Chip Node C0060
Watchdog Execution Environment Node C0061
Deployment View, L2 Software [subsystem]
General Purpose Partition 1 Node C0062
Deployment View, L2 Software [subsystem]
General Purpose Partition 2 Node C0063
Deployment View, L2 Software [subsystem]
Base Logic SW Partition Node C0064
Requirements and Goals
Requirements and Goals UMLUseCaseDiagram D0023
This section shows the goals of the software development for the MoD5G (Problem Space, Software Level L3)
In gray, the use cases on system level L1 are repeated from Requirements and Goals to show the refinement to software-only use cases shown in black.
Requirements and Goals, Requirements and Goals, Scope and Context, Deployment View
Mouse Droid MoD5G mouse-droid Component C0004
The Mouse Droid (MoD5G) is a repair droid that can be instructed to perform a mission and which then autonomously selects tactics to achieve the mission goals.
+-- Drive to location Association R0003
+-- Repair using tools Association R0004
Requirements and Goals, L1 Requirements View, Requirements and Goals
Drive to location goal UseCase C0007
The mouse droid can explore its environment and calculate a route from its actual position to the target location.
- The mouse droid explores its environment
- The mouse droid enriches an internally memorized map
- The mouse droid calculates a route
- The mouse droid drives along the calculated route
- The mouse droid re-caclulates the route in case of new environment data
- The mouse droid reaches the target location
pre: defined mission Property F0032
··> Plan tasks Include R0091
··> Explore Environment Include R0234
··> Perform Movement Include R0235
Requirements and Goals, L1 Requirements View, Requirements and Goals
Repair using tools goal UseCase C0008
The mouse droid has a couple of tools inside its chassis.
- The mouse droid uses a screw diver to untighten damaged parts
- The mouse droid uses a gripper to move the damaged part out of the way
- The mouse droid uses a gripper to put a spare part from its internal cargo bin to the target place
- The mouse droid uses a screw diver to tighten replaced parts
- The mouse droid uses a gripper to move the damaged part into its internal cargo bin.
(see L2 Mechanics)
··> Plan tasks Include R0090
··> Steer motors of tools Include R0233
Requirements and Goals, L3 Requirements
Explore Environment env-perception UseCase C0067
When the mouse droid is missing relevant data on the environment, it plans a list of actions that suits the purpose of gaining the missing knowledge.
Perform Movement UseCase C0068
Requirements and Goals, L3 Requirements
Steer motors of tools UseCase C0069
··> Base Micro Controller Include R0255
Plan tasks UseCase C0070
The mouse droid creates a list of actions to fulfill the given mission. If data on the environment is missing, it plans an explortion task and re-plans the action list later.
Main Board Logic, Requirements and Goals, L2 Software [subsystem]
High Performance SoC Block C0056
This block provides an execution environment for algorithms that is optimized for high performance.
+-- Explore Environment Association R0258
+-- Plan tasks Association R0259
Base Logic Board, Requirements and Goals, L2 Electric Parts and Electronics, L2 Software [subsystem]
Base Micro Controller Block C0051
The base micro controller consists of
- logic unit
- data storage
- persistent data+logic storage
- self supervision (by ECC and lockstep-cores)
- HW watchdog
- clock
- temperature sensor
- io ports
This block is optimized for providing a reliable execution of algorithms, see Quality Requirements.
Temperature sensor Port F0010
clock comm I2C Port F0007
Main Board Connector Port F0009
Speaker I2S Port F0004
Motor Control I2C Port F0003
Diag JTAG Port F0005
reset cmd Port F0006
+-- Steer motors of tools Association R0256
+-- Perform Movement Association R0257
L3 Requirements
L3 Requirements SysMLRequirementDiagram D0045
This diagram shows examples of system level L3 requirements.
L1 Requirements View, L3 Requirements
L1Req: Recognize paths env-perception Requirement C0149
The MoDG5 shall use redundant sensor data to calculate paths that it can drive along.
L1 Requirements View, L3 Requirements
L1Req: Position screw driver Requirement C0150
The MoDG5 shall bring the screw driver into a given 3D position.
Requirements and Goals, L3 Requirements
Explore Environment env-perception UseCase C0067
When the mouse droid is missing relevant data on the environment, it plans a list of actions that suits the purpose of gaining the missing knowledge.
Requirements and Goals, L3 Requirements
Steer motors of tools UseCase C0069
L3 Requirements, Environment Capture
L3Req: Calc 3D scene from 2 cameras env-perception Requirement C0151
The Main Logic Board shall create a 3D model of the environment based on 2 camera images.
··> Explore Environment Trace R0248
··> L1Req: Recognize paths Trace R0249
Base Logic Board, L3 Requirements, L1 Physical View, Solution Strategy, L2 Electric Parts and Electronics
Base Logic Board Block C0048
The base logic board consists of several electronic parts shown in Base Logic Board.
Main Board Connector Port F0031
··> L1Req: Position screw driver Trace R0247
-- Screw Driver CommunicationPath R0252
Main Board Logic, L3 Requirements, L1 Physical View, Solution Strategy, L2 Electric Parts and Electronics
Main Logic Board Block C0047
The main logic board consists of several electronic parts shown in Main Board Logic.
Base Board Connector Port F0008
Mic-Connector I2S Port F0002
Camera LVDS Port F0001
··> L1Req: Recognize paths Trace R0246
status and control -- Base Logic Board CommunicationPath R0280
L3 Requirements, System Control
L3Req: Operate motors of tool-arm Requirement C0152
The Base Logic Board shall steer the motors of the tool-arm to a given 3D position.
··> L1Req: Position screw driver Trace R0250
··> Steer motors of tools Trace R0251
Screw Driver Block C0037
L2 Mechanics, L3 Requirements, L2 Electric Parts and Electronics
Camera env-perception Block C0041
-- Main Logic Board CommunicationPath R0051
Constraints
Constraints SysMLRequirementDiagram D0024
This section explains the major obstacles, that need to be considered when designing a solution to reach the project goals. (Problem Space, Software Level L3)
Constraints, Architecture Decisions
Self-Preservation Requirement C0081
In case a wookiee growls at the MoD5G, it shall flee for self-preservation
Quality Tree, Constraints, Quality Scenarios, Quality Requirements
Interoperability SW-subcharacterisitc Requirement C0123
The programming and charging interfaces
of the MoD5G shall be compatible to
- old republic terminals
- imperial terminals
Scope and Context
Scope and Context UMLComponentDiagram D0025
This section shows the organizational contexts of development and operational environments. (Problem Space, Software Level L3)
Imperial Operator Actor C0082
program --> Mouse Droid MoD5G Association R0113
Operator of the old republic Actor C0083
program --> Mouse Droid MoD5G Association R0112
Requirements and Goals, Requirements and Goals, Scope and Context, Deployment View
Mouse Droid MoD5G mouse-droid Component C0004
The Mouse Droid (MoD5G) is a repair droid that can be instructed to perform a mission and which then autonomously selects tactics to achieve the mission goals.
Solution Strategy
Solution Strategy UMLComponentDiagram D0026
This section shows the most fundamental principles of the software design. (Solution Space, Software Level L3)
Environment Capture, Solution Strategy, Building Block View, Deployment View
Environment Capture main_logic Package C0118
Environment Model Composer Sequence, Solution Strategy, Building Block View, Deployment View
Tactics Calculator main_logic Component C0108
Calculate tactics based on given strategy and current situation model
System Control, Solution Strategy, Building Block View, Deployment View
System Control base_logic Package C0119
Base Software Structure Comment C0121
The software is basically structured into three parts:
- environment model generation
- calculating actions
- controlling execution of actions
Building Block View, Solution Strategy, Building Block View
Software Parts SW Package C0020
The software consists of control logic, initial data that was integrated at the factory and learned data that is aggregated during operation.
These software items are split over two logical boards and subdivided into independent execution partitions.
+-- Tactics Calculator Association R0236
+-- Environment Capture Association R0241
+-- System Control Association R0242
Building Block View
Building Block View UMLComponentDiagram D0027
This section shows the parts of the MoD5G software (Solution Space, Software Level L3)
Environment Capture, Environment Model Composer Sequence, Building Block View, Deployment View
Video Capture env-perception Component C0106
actual scene -- Environment Model Composer CommunicationPath R0155
Environment Capture, Environment Model Composer Sequence, Building Block View, Deployment View
Audio Capture env-perception Component C0107
actual scene -- Environment Model Composer CommunicationPath R0154
Environment Model Composer Sequence, Solution Strategy, Building Block View, Deployment View
Tactics Calculator main_logic Component C0108
Calculate tactics based on given strategy and current situation model
Environment Model Composer Sequence, System Control, Building Block View, Deployment View
Motor Controller Component C0109
Move motors according to calculated tactics
movement info -- Environment Model Composer CommunicationPath R0153
Environment Capture, Solution Strategy, Building Block View, Deployment View
Environment Capture main_logic Package C0118
+-- Environment Model Composer Association R0152
+-- Video Capture Association R0148
+-- Audio Capture Association R0149
System Control, Solution Strategy, Building Block View, Deployment View
System Control base_logic Package C0119
+-- SW Watchdog Association R0174
+-- Motor Controller Association R0151
Environment Capture, Environment Model Composer Sequence, Building Block View, Deployment View
Environment Model Composer env-perception Component C0120
-- Tactics Calculator CommunicationPath R0156
System Control, Building Block View, Crosscutting Concepts
SW Watchdog Component C0129
The SW Watchdog shall check
- validity of data as well as
- validity of sequence of checkpoints
received from software components
on the Main Logic Board.
See also Crosscutting Concepts.
Building Block View, Solution Strategy, Building Block View
Software Parts SW Package C0020
The software consists of control logic, initial data that was integrated at the factory and learned data that is aggregated during operation.
These software items are split over two logical boards and subdivided into independent execution partitions.
+-- Tactics Calculator Association R0236
+-- Environment Capture Association R0241
+-- System Control Association R0242
Environment Capture
Environment Capture UMLComponentDiagram D0046
This diagram shows the software components that perceive the the outer environment and create a model from this data.
L3 Requirements, Environment Capture
L3Req: Calc 3D scene from 2 cameras env-perception Requirement C0151
The Main Logic Board shall create a 3D model of the environment based on 2 camera images.
Environment Capture, Environment Model Composer Sequence, Building Block View, Deployment View
Audio Capture env-perception Component C0107
actual scene -- Environment Model Composer CommunicationPath R0154
Environment Capture, Solution Strategy, Building Block View, Deployment View
Environment Capture main_logic Package C0118
+-- Environment Model Composer Association R0152
+-- Video Capture Association R0148
+-- Audio Capture Association R0149
+-- Environment Model Association R0261
Environment Capture, Environment Model Composer Sequence, Building Block View, Deployment View
Video Capture env-perception Component C0106
actual scene -- Environment Model Composer CommunicationPath R0155
Environment Capture, Environment Model Composer Sequence, Building Block View, Deployment View
Environment Model Composer env-perception Component C0120
··> L3Req: Calc 3D scene from 2 cameras Trace R0254
creates ··> Environment Model Dependency R0260
Environment Model data Class C0111
The enironment model refers to the (limited) knowledge of the software on the real environment.
System Control
System Control UMLComponentDiagram D0047
This diagram shows the software components that perceive MoD5G internal sensor data and steer the actuators of the MoD5G.
L3 Requirements, System Control
L3Req: Operate motors of tool-arm Requirement C0152
The Base Logic Board shall steer the motors of the tool-arm to a given 3D position.
System Control, Solution Strategy, Building Block View, Deployment View
System Control base_logic Package C0119
+-- SW Watchdog Association R0174
+-- Motor Controller Association R0151
Environment Model Composer Sequence, System Control, Building Block View, Deployment View
Motor Controller Component C0109
Move motors according to calculated tactics
··> L3Req: Operate motors of tool-arm Trace R0253
System Control, Building Block View, Crosscutting Concepts
SW Watchdog Component C0129
The SW Watchdog shall check
- validity of data as well as
- validity of sequence of checkpoints
received from software components
on the Main Logic Board.
See also Crosscutting Concepts.
Runtime View
Runtime View UMLActivityDiagram D0028
This section shows the dynamic behavior of the software (Solution Space, Software Level L3)
This diagram shows the software states embedded in the system states. See Power Modes.
Power Modes, Power Mode Timings, Runtime View
power::booting Activity C0024
+-- sw::sync Association R0107
+-- sw::start Association R0099
+-- sw::par Association R0100
+-- sw::boot_main_board Association R0098
+-- sw::booted Association R0110
+-- sw::boot_base_board Association R0097
ready --> power::full_operation ControlFlow R0016
Power Modes, Power Mode Timings, Runtime View
power::full_operation Activity C0025
While the MoD5G is in full_operation state, all software parts are running and able to react on input data.
+-- sw::op_sync Association R0117
+-- sw::op_end Association R0115
+-- sw::op_par Association R0116
+-- sw::op_start Association R0114
+-- sw::run_base Association R0105
+-- sw::run_main Association R0104
next steps are planned --> power::energy_saving ControlFlow R0017
mission tactics are planned, no need to adapt
supervision fault --> power::booting ControlFlow R0033
Power Modes, Power Mode Timings, Runtime View
power::energy_saving Activity C0026
+-- sw::run_base_only Association R0106
external event --> power::full_operation ControlFlow R0018
external event causes re-evaluating tactics
supervision fault --> power::booting ControlFlow R0032
sw::boot_base_board Activity C0072
--> sw::sync ControlFlow R0109
sw::boot_main_board Activity C0073
--> sw::sync ControlFlow R0108
sw::start InitialNode C0074
--> sw::par ControlFlow R0101
sw::par ForkNode C0075
--> sw::boot_main_board ControlFlow R0102
--> sw::boot_base_board ControlFlow R0103
sw::run_main Activity C0076
--> sw::op_sync ControlFlow R0123
sw::run_base Activity C0077
--> sw::op_sync ControlFlow R0122
sw::run_base_only Activity C0078
sw::sync JoinNode C0079
--> sw::booted ControlFlow R0111
sw::booted ActivityFinalNode C0080
sw::op_start InitialNode C0084
--> sw::op_par ControlFlow R0119
sw::op_end ActivityFinalNode C0085
sw::op_par ForkNode C0086
--> sw::run_main ControlFlow R0120
--> sw::run_base ControlFlow R0121
sw::op_sync JoinNode C0087
--> sw::op_end ControlFlow R0118
Environment Model Composer Sequence
Environment Model Composer Sequence UMLInteractionDiagram/sequence D0037
This diagram shows the typical communication sequence to compose the environment model.
Environment Model Composer Sequence, System Control, Building Block View, Deployment View
Motor Controller Component C0109
Move motors according to calculated tactics
step count of movement motors --> Environment Model Composer Message R0166
step count of steering and movement motors
Environment Model Composer Sequence, Solution Strategy, Building Block View, Deployment View
Tactics Calculator main_logic Component C0108
Calculate tactics based on given strategy and current situation model
calculate action list -->> Tactics Calculator Message R0172
calculate action list to follow the given strategy
provide list of next actions --> Motor Controller Message R0167
update limp home action list (for emergency) --> Motor Controller Message R0168
For the emergency case, update the limp home action list
Environment Capture, Environment Model Composer Sequence, Building Block View, Deployment View
Environment Model Composer env-perception Component C0120
create 3D scene -->> Environment Model Composer Message R0171
create 3D scene based on sensors, status and history.
composed 3D scene --> Tactics Calculator Message R0165
Environment Capture, Environment Model Composer Sequence, Building Block View, Deployment View
Audio Capture env-perception Component C0107
analyze audio signal env-perception -->> Audio Capture Message R0169
list of detected audio sources env-perception --> Environment Model Composer Message R0164
Environment Capture, Environment Model Composer Sequence, Building Block View, Deployment View
Video Capture env-perception Component C0106
analyze video signal env-perception -->> Video Capture Message R0170
3D scene of visible environment env-perception --> Environment Model Composer Message R0163
Environment Model Composer Sequence
Persist List Comment C0142
the action list shall be persisted, so that after a sudden reboot, the next actions are immediately available.
··> Tactics Calculator Dependency R0220
Deployment View
Deployment View UMLDeploymentDiagram D0029
This section shows the deployment of the solution into the environment. (Solution Space, Software Level L3)
Environment Model Composer Sequence, System Control, Building Block View, Deployment View
Motor Controller Component C0109
Move motors according to calculated tactics
movement info -- Environment Model Composer CommunicationPath R0153
··> Base Logic SW Partition Deployment R0200
Deployment View, L2 Software [subsystem]
Base Logic SW Partition Node C0064
Deployment View, L2 Software [subsystem]
General Purpose Partition 2 Node C0063
Environment Model Composer Sequence, Solution Strategy, Building Block View, Deployment View
Tactics Calculator main_logic Component C0108
Calculate tactics based on given strategy and current situation model
··> General Purpose Partition 2 Deployment R0202
Environment Capture, Environment Model Composer Sequence, Building Block View, Deployment View
Audio Capture env-perception Component C0107
actual scene -- Environment Model Composer CommunicationPath R0154
··> General Purpose Partition 1 Deployment R0204
Deployment View, L2 Software [subsystem]
General Purpose Partition 1 Node C0062
Deployment View, L2 Software [subsystem]
Real Time Video Processing Chip Node C0060
Environment Capture, Environment Model Composer Sequence, Building Block View, Deployment View
Video Capture env-perception Component C0106
actual scene -- Environment Model Composer CommunicationPath R0155
··> Real Time Video Processing Chip Deployment R0201
Environment Capture, Environment Model Composer Sequence, Building Block View, Deployment View
Environment Model Composer env-perception Component C0120
-- Tactics Calculator CommunicationPath R0156
··> General Purpose Partition 1 Deployment R0203
Environment Capture, Solution Strategy, Building Block View, Deployment View
Environment Capture main_logic Package C0118
+-- Environment Model Composer Association R0152
+-- Video Capture Association R0148
+-- Audio Capture Association R0149
System Control, Solution Strategy, Building Block View, Deployment View
System Control base_logic Package C0119
+-- Motor Controller Association R0151
Crosscutting Concepts
Crosscutting Concepts UMLComponentDiagram D0030
This section shows the recurring concepts within the the designed solution. (Solution Space, Software Level L3)
Crosscutting Concepts, Risks and Technical Debts
Fault Detection (main logic) Comment C0127
Logic and data is supervised
by the SW Watchdog
located on the Base Micro Controller.
Every software component
on the Main Logic Board
shall check processed data
and report its health to the SW Watchdog
as well as passed checkpoints in the logic.
··> SW Watchdog Dependency R0175
Fault Detection (base logic) Comment C0128
The hardware of the Base Micro Controller enables logic and data supervision. Therefore no extra software solution is implemented to monitor the base logic.
··> SW Watchdog Dependency R0198
System Control, Building Block View, Crosscutting Concepts
SW Watchdog Component C0129
The SW Watchdog shall check
- validity of data as well as
- validity of sequence of checkpoints
received from software components
on the Main Logic Board.
See also Crosscutting Concepts.
Architecture Decisions
Architecture Decisions decision UMLComponentDiagram D0031
This section documents the major design decisions. (Solution Space, Software Level L3)
Wookiee Detection decision Comment C0131
Challenge: Detect presense of a Wookiee
Alt-1: Detect a growling wookie only by
analyzing the audio spectrum
recorded from the microphone.
- pro: simple to implement
- con: may produce false alarms
Alt-2: Combine the Video and the Audio
sensor data to better distinguish
a growling wookie from a shouting officer.
- pro: better recognize wookiees
- con: dependency on video processing
Decision: Alt-1
Rationale: Reacting on a false alarm
is not mission-critical.
··> Self-Preservation Dependency R0177
Constraints, Architecture Decisions
Self-Preservation Requirement C0081
In case a wookiee growls at the MoD5G, it shall flee for self-preservation
Quality Requirements
Quality Requirements UMLComponentDiagram D0032
This section shows the major quality scenarios. (Problem Space, Software Level L3)
Similar to Quality Requirements for system level L1, this section shows quality expectations: The WHAT shall be implemented, not the HOW.
Quality Tree, Quality Requirements, Quality Requirements
Compatibility quality_characteristic Requirement C0122
Compatibility defines a set of attributes that measures how well data and messages can be exchanged with other programs and/or versions.
Quality Tree, Constraints, Quality Scenarios, Quality Requirements
Interoperability SW-subcharacterisitc Requirement C0123
The programming and charging interfaces
of the MoD5G shall be compatible to
- old republic terminals
- imperial terminals
··> Compatibility Refine R0158
Quality Tree
Quality Tree SysMLRequirementDiagram D0043
When specifying quality requirements, these are categorized by two dimensions:
1) Which characteristic do they affect
2) Which use case do they serve
Thich chapter lists the quality requirements ordered by their main characteristic.
Old Republic Programming IF SW-attribute Requirement C0124
The old republic protocol for programming a droid shall be supported.
··> Interoperability Refine R0159
Imperial Programming IF SW-attribute Requirement C0125
The imperial protocol for programming a droid shall be supported.
··> Interoperability Refine R0160
Universial Charging IF SW-attribute Requirement C0126
The intergalactic standard protocol for power charging shall be supported.
··> Interoperability Refine R0161
Quality Tree, Constraints, Quality Scenarios, Quality Requirements
Interoperability SW-subcharacterisitc Requirement C0123
The programming and charging interfaces
of the MoD5G shall be compatible to
- old republic terminals
- imperial terminals
··> Compatibility Refine R0158
Quality Tree, Quality Requirements, Quality Requirements
Compatibility quality_characteristic Requirement C0122
Compatibility defines a set of attributes that measures how well data and messages can be exchanged with other programs and/or versions.
Quality Scenarios
Quality Scenarios SysMLRequirementDiagram D0042
When specifying quality requirements, these are categorized by two dimensions:
1) Which characteristic do they affect
2) Which use case do they serve
Thich chapter lists the use cases which have special importance for quality requirements.
Mixed standards of terminals UseCase C0145
precondition:
- The MoD5G operates in an environment
providing mixed terminal standards
trigger:
- The MoD5G drives to a charging or programming terminal
which complied to either old republic or imperial standard.
scenario:
- The MoD5G determines the applicable standard
- The MoD5G uses the terminal for programming or charging
··> Interoperability Trace R0227
Quality Tree, Constraints, Quality Scenarios, Quality Requirements
Interoperability SW-subcharacterisitc Requirement C0123
The programming and charging interfaces
of the MoD5G shall be compatible to
- old republic terminals
- imperial terminals
Risks and Technical Debts
Risks and Technical Debts UMLComponentDiagram D0033
This section lists the risks and not-yet-addressed requirements. (Solution Space, Software Level L3)
Fault Detection Strategy may fail Comment C0130
The fault detection strategy for
logic and data on the Main Logic Board
allows for unnoticed faults:
Not every error in logic can be detected
by checkpoints only.
··> Risk: Wrong tactic is calculated Dependency R0181
Crosscutting Concepts, Risks and Technical Debts
Fault Detection (main logic) Comment C0127
Logic and data is supervised
by the SW Watchdog
located on the Base Micro Controller.
Every software component
on the Main Logic Board
shall check processed data
and report its health to the SW Watchdog
as well as passed checkpoints in the logic.
··> Risk: Wrong tactic is calculated Dependency R0199
Risk: Wrong tactic is calculated Requirement C0134
- cause/fault: Due to cosmic rays,
the main logic board performs a miscalculation
that goes unnoticed by control flow supervision
- risk/failure: the MoD5G calculates a tactic that
results in falling off a cliff
Glossary
Glossary UMLClassDiagram D0034
This section explains the used terms. (Domain and Solution Space, Software Level L3)
Situation Model data Class C0110
The situation model refers to the (limited/erroneous) knowledge of the software on environment and status.
o-- MoD5G-Status Model Association R0142
o-- Environment Model Association R0143
Environment Model data Class C0111
The enironment model refers to the (limited) knowledge of the software on the real environment.
observe by sensors env-perception ··> Real Environment Dependency R0146
Sensor data is the basis for assuming an environment model.
MoD5G-Status Model data Class C0112
The status model refers to the (limited) knowledge of the software on the real status.
observe ··> MoD5G Real Status Dependency R0147
Sensor data is the basis for assuming a status model. The algorithm for deriving a status model shall take into account that a sensor may be defect and/or a measured value may indicate a defect (which again may have several causes).
Real Situation Class C0113
The real situation refers to the reality of system status and environment.
o-- MoD5G Real Status Association R0144
o-- Real Environment Association R0145
Real Environment Class C0114
The real environment refers to the physical environment of the system.
MoD5G Real Status Class C0115
The real status refers to the real system status of the MoD5G. This may differ from what the sensors report.
Runtime View
Runtime View UMLInteractionDiagram/overview D0007
This section shows the dynamic behavior of the system (Solution Space, System Level L1)
start operation InitialNode C0153
-->> orthogonal Message R0262
orthogonal ForkNode C0154
-->> Health States Message R0263
-->> Power Modes Message R0264
Power Modes
Power Modes UMLActivityDiagram D0020
This diagram shows the power states that are globally valid to all parts of the system.
Power Modes, Power Mode Timings
power::startup InitialNode C0023
external trigger or timer wakeup --> power::booting ControlFlow R0015
Power Modes, Power Mode Timings, Runtime View
power::booting Activity C0024
ready --> power::full_operation ControlFlow R0016
Power Modes, Power Mode Timings, Runtime View
power::full_operation Activity C0025
While the MoD5G is in full_operation state, all software parts are running and able to react on input data.
next steps are planned --> power::energy_saving ControlFlow R0017
mission tactics are planned, no need to adapt
stop operation --> power::off ControlFlow R0019
stop operation, set wakeup time
supervision fault --> power::booting ControlFlow R0033
Power Modes, Power Mode Timings, Runtime View
power::energy_saving Activity C0026
external event --> power::full_operation ControlFlow R0018
external event causes re-evaluating tactics
supervision fault --> power::booting ControlFlow R0032
Power Modes, Power Mode Timings
power::off ActivityFinalNode C0027
+-- power::booting Association R0192
+-- power::energy_saving Association R0193
+-- power::full_operation Association R0194
+-- power::startup Association R0195
+-- power::off Association R0196
Power Mode Timings
Power Mode Timings UMLInteractionDiagram/timing D0041
This diagram shows the expected startup and shutdown timings.
Power Modes, Power Mode Timings
power::off ActivityFinalNode C0027
-->> power::startup Message R0209
Power Modes, Power Mode Timings, Runtime View
power::full_operation Activity C0025
While the MoD5G is in full_operation state, all software parts are running and able to react on input data.
sleep -->> power::energy_saving Message R0212
shutdown -->> power::off Message R0215
Power Modes, Power Mode Timings
power::startup InitialNode C0023
wakeup (0 ms) -->> power::booting Message R0210
Power Modes, Power Mode Timings, Runtime View
power::booting Activity C0024
run (2300 ms) -->> power::full_operation Message R0211
Power Modes, Power Mode Timings, Runtime View
power::energy_saving Activity C0026
wakeup (0 ms) -->> power::energy_saving Message R0213
run (500 ms) -->> power::full_operation Message R0214
max 2300 msec Comment C0139
a ··> power::booting Dependency R0218
b ··> power::full_operation Dependency R0216
max 500 msec Comment C0140
c ··> power::energy_saving Dependency R0219
d ··> power::full_operation Dependency R0217
Health States
Health States UMLStateMachineDiagram D0021
This diagram shows the health states of the MoD5G system.
health::factory InitialNode C0028
factory initial test --> health::operation Transition R0207
health::disassembly ActivityFinalNode C0029
health::healthy StateMachine C0030
accident or ageing --> health::slightly_damaged Transition R0021
severe accident --> health::damaged Transition R0029
severe accident --> health::limp_home Transition R0030
health::slightly_damaged StateMachine C0031
accident --> health::limp_home Transition R0022
severe accident --> health::damaged Transition R0031
Health States, Risks and Technical Debts
health::limp_home StateMachine C0032
In case the full operation is not possible anymore, the MoD5G shall drive back to the home charging station.
accident --> health::damaged Transition R0023
health::damaged StateMachine C0033
decision for termination --> health::operation Transition R0206
health::operation StateMachine C0034
op_start Pseudostate F0019
no_op Pseudostate F0018
+-- health::limp_home Association R0024
+-- health::slightly_damaged Association R0025
+-- health::healthy Association R0026
+-- health::damaged Association R0027
--> health::disassembly ControlFlow R0205
--> health::healthy Transition R0208
+-- health::factory Association R0189
+-- health::operation Association R0190
+-- health::disassembly Association R0191
Deployment View
Deployment View UMLDeploymentDiagram D0008
This section shows the deployment of the solution into the environment. (Solution Space, System Level L1)
Space Station Node C0095
+-- Programming Terminal Association R0129
+-- Charging Terminal Association R0130
+-- Maintenance Booth Association R0131
+-- Mouse Droid MoD5G Association R0128
Requirements and Goals, Requirements and Goals, Scope and Context, Deployment View
Mouse Droid MoD5G mouse-droid Component C0004
The Mouse Droid (MoD5G) is a repair droid that can be instructed to perform a mission and which then autonomously selects tactics to achieve the mission goals.
Programming Terminal Node C0096
Charging Terminal Node C0097
Maintenance Booth Node C0098
Crosscutting Concepts
Crosscutting Concepts CFUBoxDiagram D0009
This section shows the recurring concepts within the the designed solution. (Solution Space, System Level L1)
Motor Type Comment C0099
All motors are electrical step motors.
Step motors can be controlled
to move a defined number of steps
forward or backwards.
Note that there are conditions
when the actual number of steps
is not equal to the previously requested
number of steps, e.g. when accellerating
or slowing down too fast.
Architecture Decisions
Architecture Decisions decision UMLComponentDiagram D0010
This section documents the major design decisions. (Solution Space, System Level L1)
Constraints, Architecture Decisions
Cosmic Rays environment Requirement C0002
The droid shall ensure data and program integrity.
It shall continue operation after cosmic rays have interfered with data storage or program execution.
Corrupted data must not be stored permanently.
2 of 3 Voter rejected_alternative Requirement C0100
In order to support integrity of the system, the logic boards and the data storages are deployed three times as three identical parts.
All three parts shall produce the same outcomes given the same input.
If one deviates, it's result is ignored and the part is rebooted.
rejected alternative could-trace ··> Cosmic Rays Trace R0135
Cosmic Rays Information Comment C0101
When a cosmic ray interferes with the system, the logic or the processed data gets corrupted.
provides background ··> Cosmic Rays Dependency R0132
Watchdog Supervision chosen_alternative Requirement C0102
In order to support integrity of the logic and data,
a multi-stage hierarchy supervision shall be implemented.
Software watchdogs shall supervise the running software parts
in a way that logic errors and corrupted data can be detected.
A hardware watchdog shall supervise the software watchdogs.
In case of a failure in the supervised logic/data, the system shall reboot.
In case of a failure in the monitors, the system may reboot
or it shall fall back to a valid supervision mode.
··> Cosmic Rays Trace R0134
Decision: Watchdog decision Comment C0103
Arguments:
- The 2 of 3 voter is easier to implement but causes higher hardware costs.
- The watchdog supervision requires higher engineering efforts but is cheaper in production.
The watchdog supervision shall be implemented.
selected solution ··> Watchdog Supervision Dependency R0133
Quality Requirements
Quality Requirements UMLComponentDiagram D0011
This section shows the major quality requrements and scenarios. (Problem Space, System Level L1)
In the following, requirements and scenarios are selected that show the quality expectations: The WHAT shall be implemented, not the HOW.
Usability quality_characteristic Requirement C0009
Usability defines a set of attributes that measures how easy to learn and use the program is.
Maintainability, Quality Tree, Quality Requirements
Maintainability quality_characteristic Requirement C0010
Maintainability defines a set of attributes that influence how to analyze and mitigate defects that occur during operation.
Reliability quality_characteristic Requirement C0011
Reliability defines a set of attributes that measures how mature and fault-tolerant the software is.
Quality Tree, Quality Requirements, Quality Requirements
Compatibility quality_characteristic Requirement C0122
Compatibility defines a set of attributes that measures how well data and messages can be exchanged with other programs and/or versions.
Quality Tree
Quality Tree SysMLRequirementDiagram D0039
This section shows the quality requirements ordered by quality characteristics.
Maintainability, Quality Tree, Quality Requirements
Maintainability quality_characteristic Requirement C0010
Maintainability defines a set of attributes that influence how to analyze and mitigate defects that occur during operation.
Maintainability, Quality Tree, Quality Scenarios
Analyzability SW_sub-characteristic Requirement C0014
The MoD5G shall allow to analyze faults that occurred during operation.
··> Maintainability Refine R0009
Maintainability, Quality Tree, Quality Scenarios
Repairability HW_sub-characteristic Requirement C0012
The MoD5 hardware parts shall be exchangeable in case they are damaged.
··> Maintainability Refine R0007
Maintainability
Maintainability SysMLRequirementDiagram D0015
This diagram shows the quality requirements related to the characteristic "Maintainability".
Maintainability, Quality Tree, Quality Requirements
Maintainability quality_characteristic Requirement C0010
Maintainability defines a set of attributes that influence how to analyze and mitigate defects that occur during operation.
Maintainability, Quality Tree, Quality Scenarios
Repairability HW_sub-characteristic Requirement C0012
The MoD5 hardware parts shall be exchangeable in case they are damaged.
··> Maintainability Refine R0007
30 years spare-parts supply HW-attribute Requirement C0013
The mechanical and electrical/electronics parts of the MoD5 shall be produceable in identical or similar form and quality for 30 years after production of the unit.
··> Repairability Refine R0008
Maintainability, Quality Tree, Quality Scenarios
Analyzability SW_sub-characteristic Requirement C0014
The MoD5G shall allow to analyze faults that occurred during operation.
··> Maintainability Refine R0009
Self-Diagnosis SW-attribute Requirement C0015
At the maintenance booth, the MoD5G shall provide an error log. This error log contains detected errors from operation and related environment conditions. It also lists possible causes(faults).
··> Analyzability Refine R0010
Quality Scenarios
Quality Scenarios UMLUseCaseDiagram D0040
This section shows the quality-related scenarios in which the quality requirements shown in Quality Tree are of special importance.
Spare Parts Supply quality_scenario UseCase C0017
pre-condition:
- the stock of MoD5G spare parts is empty
trigger:
- 20 years after production,
a MoD5G needs a spare part that is not available anymore
scenario:
- a service mechanic orders a batch of parts
- a factory creates the parts that fit in form, function and quality to the MoD5G
- spare parts are delivered
··> Repairability Trace R0012
Motor defect quality_scenario UseCase C0016
pre-condition:
- the MoD5G is performing a 1-day mission autonomously
trigger:
- a motor fails to operate
- the goals of the 1-day mission cannot be accomplished anymore
scenario:
- the MoD5G cancels the mission and returns to the service point
- a service mechanic reads out the error log
- the MoD5G proposes to replace the suspicious motor
- the service mechanic replaces the motor
··> Analyzability Trace R0197
Maintainability, Quality Tree, Quality Scenarios
Repairability HW_sub-characteristic Requirement C0012
The MoD5 hardware parts shall be exchangeable in case they are damaged.
Maintainability, Quality Tree, Quality Scenarios
Analyzability SW_sub-characteristic Requirement C0014
The MoD5G shall allow to analyze faults that occurred during operation.
Risks and Technical Debts
Risks and Technical Debts UMLUseCaseDiagram D0012
This section lists the risks and not-yet-addressed requirements. (Solution Space, System Level L1)
Limp home mode may fail Comment C0105
In case of a single fault, the MoD5G shall return
to the charging station.
The current design does not address the cases:
- the base logic board is damaged
- the energy cell is damaged
- the movement/steering motors are defect
comments ··> health::limp_home Dependency R0136
explains ··> Risk: MoD5G does not drive back (logic board) Dependency R0179
explains ··> Risk: MoD5G does not drive back (motors) Dependency R0229
explains ··> Risk: MoD5G does not drive back (energy) Dependency R0230
Health States, Risks and Technical Debts
health::limp_home StateMachine C0032
In case the full operation is not possible anymore, the MoD5G shall drive back to the home charging station.
Risk: MoD5G does not drive back (logic board) Risk Requirement C0133
- cause/fault: the base logic board is damaged
- risk/failure: the MoD5G cannot drive anymore
fault not handled ··> health::limp_home Trace R0180
Risk: MoD5G does not drive back (energy) Risk Requirement C0147
- cause/fault: the energy cell is damaged
- risk/failure: the MoD5G cannot drive anymore
fault not handled ··> health::limp_home Trace R0232
Risk: MoD5G does not drive back (motors) Risk Requirement C0148
- cause/fault: the ,ovement/steering motors are damaged
- risk/failure: the MoD5G cannot drive anymore
fault not handled ··> health::limp_home Trace R0231
Glossary
Glossary CFUListDiagram D0013
This section explains the used terms. (Domain and Solution Space, System Level L1)
See also Glossary for software terms.
Maintenance booth Comment C0104
A room in a star ship or on a planet
where the following tasks are performed:
- check operability of droids
- oil refill service
- repair of droids
- disintegration of old droids
Base location Comment C0143
The location where the MoD5G droid returns to when its mission is finished. This location typically provides a charging and programming terminal. This location can be re-programmed.
Stereotypes on "What to build"
Stereotypes on "What to build" UMLProfileDiagram D0049
Stereotypes on "What to build"
UML:Node Metaclass Stereotype C0165
Stereotypes on "What to build"
mouse-droid Stereotype C0163
<path d=" c 3, -0.8 4.5, 0.5 4.5, 2.5 l -8, 0 c 1, -2, 2, -3, 3, -3 c 0.5, 0 0.5, 1 0, 1 m -1.1, 0.3 l -0.2, 0.2 " fill="#bb9977" />
*-- mouse-img Association R0271
--|> UML:Node Generalization R0272
Stereotypes on "What to build"
mouse-img mouse-droid Image C0164
Stereotypes on "What to build"
UML:UseCase Metaclass Class C0170
Stereotypes on "What to build"
goal Stereotype C0171
<path fill="#aaeeff" d=" M 5,9 L 5,1 1,2.5 5,4 "/>
--|> UML:UseCase Generalization R0277
*-- flag Association R0278
Stereotypes on "What to build"
flag goal Image C0172
Stereotypes on "What to build"
UML:Actor Metaclass Class C0174
Stereotypes on "What to build"
environment Stereotype C0175
<path fill="#eeff88" d=" M 1,0 C 1,0.55 0.55,1 0,1 C -0.55,1 -1,0.55, -1,0 C -1,-0.55 -0.55,-1 0,-1 C 0.55,-1, 1,-0.55, 1,0 "/> <path d=" M 2,0 L 4,0 M 1.73,1 L 3.46,2 M 1,1.72 L 2,3.46 M 0,2 L 0,4 M -1,1.72 L -2,3.46 M -1.73,1 L -3.46,2 M -2,0 L -4,0 M -1.73,-1 L -3.46,-2 M -1,-1.72 L -2,-3.46 M 0,-2 L 0,-4 M 1,-1.72 L 2,-3.46 M 1.73,-1 L 3.46,-2 "/>
--|> UML:Actor Generalization R0281
*-- env-img Association R0282
Stereotypes on "What to build"
env-img environment Image C0176
Stereotypes on "How to achieve the goal"
Stereotypes on "How to achieve the goal" UMLProfileDiagram D0048
Stereotypes allow a classification of elements into project-specific categories.
Stereotypes on "How to achieve the goal"
UML:Component Metaclass Class C0155
Stereotypes on "How to achieve the goal"
env-perception Stereotype C0156
<path fill="#ffcc66" d=" M 0.8,0 a 0.8,0.8 0 1 0 -1.6,0 a 0.8,0.8 0 1 0 1.6,0 " /> <path d=" M 1,0 A 1,0.5 22 1 1 0.707,0.707 A 1,0.5 67 1 1 0,1 A 1,0.5 112 1 1 -0.707,0.707 A 1,0.5 157 1 1 -1,0 A 1,0.5 202 1 1 -0.707,-0.707 A 1,0.5 247 1 1 0,-1 A 1,0.5 -68 1 1 0.707,-0.707 A 1,0.5 -23 1 1 1,0 " />
--|> UML:Component Generalization R0265
*-- env-image Association R0266
Stereotypes on "How to achieve the goal"
env-image env-perception Image C0157
Stereotypes on "How to achieve the goal"
UML:Class Metaclass Class C0158
Stereotypes on "How to achieve the goal"
decision Stereotype C0159
<path d="m 8,12 l -4,7 1,1 6,0 1,-1 -4,-7 l 8,-4 9,0 l -4,7 1,1 6,0 1,-1 -4,-7 " /><path d="m 15,5 l 1,3 m 0,2 l 0,17 " />
--|> UML:Class Generalization R0267
*-- decision-img Association R0268
Stereotypes on "How to achieve the goal"
decision-img decision Image C0160
Stereotypes on "How to achieve the goal"
data Stereotype C0161
<path d="m 4,5 l 0,22 c 0,2.25 5.25,4 12,4 s 12,-1.75 12,-4 l 0,-22 " /><path d="m 4,5 c 0,-2.25 5.25,-4 12,-4 s 12,1.75
12,4 s -5.25,4 -12,4 s -12,-1.75 -12,-4 " />
--|> UML:Class Generalization R0269
*-- data-img Association R0270
Stereotypes on "How to achieve the goal"
data-img data Image C0162
Stereotypes on "How to achieve the goal"
rejected_alternative Stereotype C0166
<path d="m 1,24 4,4 22,0 4,-4 " /><path stroke="#cc0000" d="m 8,17 c 0,-4.4 3.6,-8 8,-8 s 8,3.6 8,8 s -3.6,8 -8,8 s
-8,-3.6 -8,-8 " /><path stroke="#cc0000" d="m 11,17 l 10,0 " />
*-- rejected Association R0273
--|> UML:Class Generalization R0274
Stereotypes on "How to achieve the goal"
rejected rejected_alternative Image C0167
Stereotypes on "How to achieve the goal"
chosen_alternative Stereotype C0168
<path d="m 1,24 4,4 22,0 4,-4 " /><path stroke="#00aa00" d="m 8,17 c 0,-4.4 3.6,-8 8,-8 s 8,3.6 8,8 s -3.6,8 -8,8 s
-8,-3.6 -8,-8 " /><path stroke="#00aa00" d="m 11,17 l 10,0 m -5,-5 l 0,10 " />
*-- chosen Association R0275
--|> UML:Class Generalization R0276
Stereotypes on "How to achieve the goal"
chosen chosen_alternative Image C0169