Проектиране на системно ниво. Част 1. От идея към система

Здравейте всички. Често прилагам принципите на системното инженерство в работата си и бих искал да споделя този подход с общността.

Системно инженерство - без стандарти, но просто казано, това е процес на разработване на система като доста абстрактни компоненти, без препратка към конкретни образци на устройства. По време на този процес се установяват свойствата на компонентите на системата и връзките между тях. Освен това е необходимо системата да бъде последователна и оптимална и системата да отговаря на изискванията. В този урок ще покажа техники за системно инженерство, като използвам примера за проектиране на доста проста система за контрол на достъпа (ACS).

Оформяне на първоначалната архитектура

Когато една система, без значение каква, току-що започне да се развива, в главите ни или на хартия се появяват правоъгълници със стрелки. Такива правоъгълници са компонентите системи. И стрелките са връзка между компонентите. И много често нямаме време да седим и да мислим как всички компоненти, които сме дефинирали, ще работят един с друг, и в крайна сметка започваме да създаваме куп патерици, измисляйки излишни дизайни.

Важно е да запомните, че от гледна точка на системата и нейната архитектура компонентът е доста абстрактно нещо. Например, ако нашата система има микроконтролер, тогава на архитектурно ниво за нас е важно само това да е микроконтролер, а не да е STM32, Arduino или Milander. Освен това често изобщо не ни е ясно какво точно ще има в системата и се обръщаме към системния инженеринг за разработване на изисквания за оборудване, софтуер и т.н.

За нашия пример с ACS ще се опитаме да формулираме неговата цел. Това ще ни помогне да идентифицираме неговите компоненти. И така, задачата на системата за контрол на достъпа е да допусне ограничен кръг от хора в стаята. Тоест това е интелигентна ключалка. Следователно имаме първия компонент - някакво устройство, което заключва и отключва вратата! Да му се обадим Брава за врата

Как да разберем, че човек може да влезе вътре? Не искаме да поставим пазач и да проверява паспортите, нали? Нека да дадем на хората специални карти с RFID етикети, на които ще записваме уникални идентификатори или други данни, които ни позволяват точно да идентифицираме човек. Тогава ще ни трябва някакво устройство, което може да чете тези тагове. Страхотно, имаме още един компонент, RFIDReader

Нека да погледнем отново какво имаме. RFIDReader чете някакви данни, системата за контрол на достъпа прави нещо с тях и на базата на това нещо се контролира Брава за врата. Нека зададем следния въпрос - къде да съхраняваме списъка с хора с права на достъп? Най-добрият в базата данни. Следователно нашата система трябва да може да изпраща заявки и да обработва отговори от базата данни. Така че имаме още един компонент - DBHandler. И така, получихме изключително абстрактно, но достатъчно за начало описание на системата. Ние разбираме какво трябва да прави и как работи.

Вместо лист хартия ще използвам System Composer, специален инструмент за моделиране на системни архитектури в средата Simulink, и ще създам 3 компонента. По-горе описах връзките между тези компоненти, така че нека веднага да ги свържем:

Разширяване на архитектурата

Нека да разгледаме нашата диаграма. Изглежда, че всичко е наред, но в действителност не е така. Погледнете тази система от гледна точка на потребителя - потребителят донася картата до четеца и...? Как потребителят разбира дали му е разрешен или отказан достъп? Необходимо е по някакъв начин да го уведомите за това! Затова нека добавим още един компонент - известяване на потребителя, UserNotify:

Сега нека слезем на по-ниско ниво на абстракция. Нека се опитаме да опишем някои компоненти малко по-подробно. Да започнем с компонента RFIDReader. В нашата система този компонент отговаря за четенето на RFID етикета. Неговият изход трябва да съдържа някои данни (UID, потребителски данни...). Но изчакайте, RFID, подобно на NFC, е предимно хардуер, а не софтуер! Следователно можем да приемем, че отделно имаме самия RFID чип, който предава „сурови“ данни към някакъв вид препроцесор. И така, имаме абстрактен хардуер, който може да чете RFID етикети, и абстрактен софтуер, който може да преобразува данните във формата, от който се нуждаем. Да им се обадим RFIDSензор и RFIDParser съответно. Как да покажа това в System Composer? Можете да премахнете компонент RFIDReader и вместо това да поставим два компонента, но е по-добре да не правим това, в противен случай ще загубим четливостта на архитектурата. Вместо това нека влезем в RFIDReader и да добавим 2 нови компонента:

Страхотно, сега нека да преминем към уведомяване на потребителя. Как системата ще уведоми потребителя, че му е отказан или разрешен достъп до помещенията? Човек най-добре възприема звуци и нещо, което мига. Следователно можете да издадете определен звуков сигнал, така че потребителят да обърне внимание и да мига светодиода. Нека добавим подходящите компоненти към UserNotify:

Създадохме архитектурата на нашата система, но нещо не е наред с нея. Какво? Нека да разгледаме имената на връзките. InBus и OutBus - не съвсем нормални имена, които биха помогнали на разработчика. Те трябва да бъдат преименувани:

И така, разгледахме как методите за системно инженерство се прилагат в най-грубото приближение. Възниква въпросът: защо изобщо да ги използваме? Системата е примитивна и изглежда, че свършената работа е излишна. Можете веднага да напишете код, да проектирате база данни, да пишете заявки или да запоявате. Проблемът е, че ако не обмислите системата и не разберете как нейните компоненти са свързани помежду си, тогава интегрирането на системните компоненти ще отнеме много време и ще бъде доста болезнено.

Основният извод от тази част е:

Използването на методи за системно инженерство и моделиране на архитектурата при разработването на системи позволява да се намалят разходите за интегриране на компоненти и да се подобри качеството на разработената система.

Източник: www.habr.com