S13-System Architecture Model

#requirements #systems #engineering #documentation #ops #mechanical #prgramming #electrical #strategy

1 Purpose

The purpose of this document is to standardize a process for modeling a system architecture.

2 Scope

The departments interacting with requirements:

3 Overview

Grayson Robotics bases our system architecture modeling practice on the Arcadia method.

#todo link to a Quote that links to and describes, in brief, the Arcadia method.

4 Elements of a system architecture

To achieve a winning design it is necessary for designers to fully understand the mission and gather a complete set of requirements. Without a system architecture teams run into two major problems:

  1. It is unlikely that the team would correctly and completely identify all the relevant requirements needed for a winning robot.
  2. The system design requires coordination between different engineering disciplines and they must resolve design conflicts.

In order to manufacture and assemble the robot the system architecture model must answer the question: what components will the robot be made of? To answer that we must know how we want the system to work. To know how we want the system to work we must first know what the system needs to do. To know what the system needs to do we must first know what the users of the system (our team) need to accomplish with it.

4.1 System architecture levels

The system architecture model has for levels of abstraction designed to represent the each of the four key questions we need to answer:

  1. Operational Analysis: What the users of the system need to accomplish.
  2. System Need Analysis: What the system has to accomplish for the users.
  3. Logical Architecture: How the system will work.
  4. Physical Architecture: How the system will be built.

Each level is a refinement of the level before it, with the exception of the Operational Analysis which depends on the Game Manual and Strategy.

4.2 Operational Analysis (OA)

Without considering the role of the robot, answer the question: "what does the team need to do to execute the strategy?"

The OA is for use by all departments, not just engineering. For example: operations would need it as a starting point to know what to bring to competitions and how to set up the cart.

4.3 System Needs Analysis (SA)

Given the OA and the strategy, answer the question: "Of everything the team needs to do, what will the SUD do?"

4.4 Logical Architecture (LA)

Given the SA, answer the question: "what capabilities does the robot need to fulfill the SA?" without describing any specific hardware. This allows you to describe what may become physically interdependent sub-systems as logically separate.

It may be the case that a particular mechanical device is responsible for handling two completely different functions, but it would be too limiting to decide this before all functions are enumerated. For example: in 2025 one would model the Coral and Algae lift mechanism as two separate logical components. Even though they may be the same physical hardware, they will have different requirements for handling each game element that are best discovered by considering the two system needs independently.

For another example: in 2026 you could have a logical component, Fuel Aiming Device to capture the need to aim at the hopper. There's however no one component or sub-assembly that would cover everything that entails. You have to consider the camera and software, but also decide whether to use a turret or the drive train. In the latter case, in the Physical Architecture, you would assign the drive train to deal with part of this role. You would also want to consider whether the launch angle is best set with a moving hood or only by variable speed control of the launch wheels.

4.4.1 Creating LA components

Create a component by completing this sentence: "We need a part that..."

4.5 Physical Architecture (PA)

What specific parts the robot is made of and how it does what it does. The PA takes the abstractions created in the LA and assigns specific components to the logical sub-systems described by the LA.

In addition to written Requirements, the PA documentation includes: