System Overview Diagram
Contents
What
A overview in blocks of the system-to-be.
The System Overview Diagram, can help you identify the building blocks of your system, without having to determine, yet, if they are to be Hardware, Software or mechanics.
This diagram is not to confuse with the Block Diagram, that gives a bit more detailed information. The System Overview Diagram is drawn before splitting into HW and SW block diagrams.
Anyone, with a bit of technical insight should be able to identify with the blocks in this diagram.
How
The dish
A diagram showing the system at-a-glance.
Ingredients
Process
The Rich Picture basically shows the environment in which system-to-be should operate and the system-to-be is not a part of the Rich Picture.
In order to make the first overview of the system-to-be, the interfaces which the system needs can be found in the Rich Picture.
From the System Definition, the functionality can be determined.
Compose a diagram using squares to indicate a block that isolates related functionality. Do not at all think how the functionality can be implemented. Decisions about how to implement a specific functionality will be made later when considerations about the technical platform are done.
Use simple lines or arrowed lines to indicate connections between the blocks. The arrows can indicate information flow direction. Descriptions or names can indicate the type of information flowing in the connection. Do not consider number of wires, bits or the like at this point.
Why
Often the developers "think" in isolated "boxes" that have related functionality abstracting the environment with which the system-to-be interacts. In software development, these boxes are often called classes. In hardware development, the boxes are block of related components forming an unambiguous function.
In the very early phases of a development project, a diagram with boxes can be used to model the system-to-be in overall terms. Early in the development process, there is no decision about how the functionality should be implemented, but only that the functionality is needed. Engineers tend to immediately go into "implementation mode", i.e. to immediately determine how a given functionality can be implemented. This is not a recommended way to go, because one tends to overlook obvious or simple solutions or even change the requirements away from what the customer expects, since the developer is locked on a specific solution that is well-known beforehand.
Later in the process, the System Overview Diagram will be more detailed and probably split into a hardware block diagram and a class diagram for the software part. But the decision about what should be implemented in hardware and which parts in software should be made on an enlightened base, when all requirements have been analysed in detail.
Example
Note! this example, is not -yet consistent with the Rich Picture and the System Definition
Overall system overview diagram
for building an android powered diy-segway, we start with an owerall system overview diagram.
This can have many shapes, and looks, depending on what is given, and what is unknown.
In our case, we know that a diy-segway has two wheels with engines, and an Android phone, it also needs to be able to carry a fully grown human being.
From theese informations following system overwiew diagram is sketched:
Control system overview diagram
The control system, is pretty much, where the magic is going to happen. We do not, yet decide any technical solutions
We know that the vehicle will have to be equipped with sensors, to sense things like, speed, direction, accelleration, and perhaps angular rotation.
We know, that there are a lot of different options, in therms of sensors, also the android phone has a lot of interresting sensors onboard.
So to summarize this, we create a block movement sensors
The user will probably be able to adjust different parmeters, monitor battery status, speed, position etc.
This gives us the block User inputs
A block for handling safety critical issues, protection of the passenger, batteries etc. are vital, hence the block safety / protection
Centrally, the data processing block is placed, this or theese block(s), coordinates and processes all incoming data, og controls the actuators (engines), so the veichle balances, and drives accordingly to the users inputs.
Also a block for controlling and handling the actuators is vital. This will drive the engines, monitor relevant ambient conditions etc.
