System level design. Part 1. From idea to system

Hi all. I often apply systems engineering principles in my work and would like to share this approach with the community.

System engineering - without standards, but in a simple way, it is the process of developing a system as rather abstract components, without being tied to specific device samples. During this process, the properties of the system components and the links between them are established. Additionally, it is required to make the system consistent and optimal, and that the system would meet the requirements. In this tutorial, I'll show you the techniques of systems engineering using the example of designing a fairly simple access control system (ACS).

We form the initial architecture

When a system, no matter what, is just beginning to be developed, rectangles with arrows appear in our head or on paper. These rectangles are Components systems. And the arrows are connections between components. And very often we do not have time to sit and think about how all those components that we have defined will work with each other, and in the end we start creating a bunch of crutches, coming up with redundant designs.

It is important to remember that from the point of view of the system and its architecture, a component is a fairly abstract thing. For example, if our system has a microcontroller, then at the architecture level it is only important for us that it is a microcontroller, and not that it is STM32, Arduino or Milandr. Moreover, it is often not clear to us what exactly will be in the system, and we turn to systems engineering to develop requirements for hardware, software, etc.

For our example with ACS, let's try to formulate its purpose. This will help us in identifying its components. So, the task of ACS is to let a limited circle of people into the room. That is, it is a smart lock. Therefore, we have the first component - a kind of device that locks and unlocks the door! Let's call it DoorLock

And how do we know that a person can get inside? We don't want to put a watchman in and check passports, do we? Let's give people special cards with RFID tags, on which we will write unique IDs or other data that will accurately identify a person. Then, we need some kind of device that can read these labels. Great, we have one more component, RFIDReader

Let's look again at what we've got. RFIDReader reads some data, the ACS system does something with them, and on the basis of this something is controlled DoorLock. Let's ask the following question - where to store a list of people with access rights? Best in database. Therefore, our system must be able to send requests and process responses from the database. So we have one more component - DBHandler. So, we have received an extremely abstract, but sufficient description of the system to begin with. We understand what it should do and how it works.

Instead of a piece of paper, I use System Composer, a special tool for modeling system architectures in Simulink, and create 3 components. I described the connections between these components above, so let's connect them right away:

System level design. Part 1. From idea to system

Extending the architecture

Let's look at our diagram. Everything seems to be fine, but it really isn't. Look at this system from the user's point of view - the user swipes the card to the reader and...? How does the user know if they are allowed or denied access? There needs to be some way to let him know! Therefore, we will add one more component - user notification, UserNotify:

System level design. Part 1. From idea to system

Now let's go down to a lower level of abstraction. Let's try to paint some components in a little more detail. Let's start with the component RFIDReader. In our system, this component is responsible for reading the RFID tag. Its output should have some data (UID, user data...). But wait, RFID, like NFC, is primarily hardware, not software! Therefore, we can assume that we separately have the RFID chip itself, which transmits the β€œraw” data to a certain preprocessor. In total, we have an abstract piece of hardware that can read RFID tags, and abstract software that can convert data into the format we need. Let's call them RFIDSensor ΠΈ RFIDParser respectively. How to display this in System Composer? You can remove the component RFIDReader and instead put two components, but it’s better not to do this, so we will lose the readability of the architecture. Instead, let's go inside RFIDReader and add 2 new components:

System level design. Part 1. From idea to system

Great, now let's move on to notifying the user. How will the system notify the user that he is denied or allowed access to the premises? A person perceives best sounds and something flashing. Therefore, you can give out a certain sound signal so that the user pays attention, and blink the LED. Let's add the appropriate components to UserNotify:

System level design. Part 1. From idea to system

We have created the architecture of our system, but there is something wrong with it. What? Let's look at the connection names. inbus ΠΈ outbus - not quite normal names that would help the developer. They need to be renamed:

System level design. Part 1. From idea to system

So, we looked at how systems engineering methods are applied in the most rough approximation. The question arises - why use them at all? The system is primitive, and it seems that the work done is redundant. It would be possible to immediately write code, design a database, write queries or solder. The problem is that if you do not think through the system, do not understand how its components are connected to each other, then the integration of the system components will take a long time and rather painfully.

The main takeaway from this part is:

The use of systems engineering and architecture modeling methods in the development of systems can reduce the cost of integrating components and improve the quality of the system being developed.

Source: habr.com

Add a comment