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

Всем привет. Я часто применяю в своей работе принципы системной инженерии и хотел бы поделиться этим подходом с сообществом.

Системная инженерия – без стандартов, а по-простому, это процесс разработки системы как достаточно абстрактных компонентов, без привязки к конкретным образцам устройств. В ходе данного процесса устанавливаются свойства компонентов системы и связи между ними. Дополнительно требуется сделать систему непротиворечивой и оптимальной и что бы система соответствовала требованиям.

В серии статей я покажу приемы системной инженерии на примере проектирования достаточно простой системы контроля доступа (СКУД).

Формируем начальную архитектуру

Когда система, не важно какая, только начинает разрабатываться, у нас в голове или на бумаге появляются прямоугольники со стрелками. Такие прямоугольники – это и есть компоненты системы. А стрелки — это соединения между компонентами. И очень часто у нас нет времени посидеть и подумать, как все те компоненты, которые мы определили будут друг с другом работать, а в итоге мы начинаем создавать кучу костылей, придумывая избыточные конструкции.

Важно помнить, что с точки зрения системы и ее архитектуры компонент – это достаточно абстрактная штука. Например, если в нашей системе есть микроконтроллер, то на уровне архитектуры нам важно только то, что это микроконтроллер, а не то, что это STM32, Arduino или Миландр. Более того, зачастую нам вообще непонятно что именно будет в системе, и мы обращаемся к системной инженерии для выработки требований к оборудованию, софту и т.д.

Для нашего примера со СКУД, попытаемся сформулировать ее предназначение. Это поможет нам в определении ее компонентов. Итак, задача СКУД – пропускать в помещение ограниченный круг людей. То есть это - умный замок. Следовательно, у нас появился первый компонент – некое устройство запирающее и отпирающее дверь! Назовем его DoorLock.

А как мы узнаем, что человек может попасть внутрь? Мы же не хотим сажать вахтера и проверять паспорта? Давайте выдавать людям специальные карточки с RFID-метками, на которые будем записывать уникальные ID или другие данные, позволяющие точно идентифицировать человека. Тогда, нам понадобится некое устройство, которое сможет читать эти метки. Прекрасно, у нас есть еще один компонент, RFIDReader.

Посмотрим еще раз на то, что у нас получилось. RFIDReader читает некие данные, система СКУД что-то с ними делает, и на основании этого чего-то управляется DoorLock. Зададим следующий вопрос – а где хранить список людей с правами доступа? Лучше всего в базе данных. Следовательно, наша система должна уметь слать запросы и обрабатывать ответы от базы данных. Таким образом у нас есть еще один компонент – DBHandler. Итак, мы получили крайне абстрактное, но достаточное для начала описание системы. Мы понимаем, что она должна делать и как это устроено.

Вместо листка бумаги я использую System Composer, специальный инструмент для моделирования архитектур систем в среде Simulink и создам 3 компонента. Выше я описал связи между эти компонентами, поэтому сразу же соединим их:

Расширяем архитектуру

Посмотрим на нашу схему. Кажется, что все хорошо, но на самом деле нет. Посмотрите на эту систему с точки зрения пользователя — пользователь подносит карту к считывателю и…? Как пользователь узнает, что ему разрешен или запрещен доступ? Необходимо как-то его еще оповещать об этом! Поэтому добавим еще один компонент - уведомление пользователя, UserNotify: А теперь спустимся на уровень абстракции пониже. Попробуем расписать некоторые компонент чуть подробнее. Начнем с компонента RFIDReader. В нашей системе этот компонент отвечает за чтение RFID-метки. На его выходе должны быть некие данные (UID, пользовательские данные…). Но постойте, RFID, как и NFC — это в первую очередь железо, а не софт! Поэтому можно допустить, что у нас отдельно есть сам чип для RFID, который передает «сырые» данные в некий предобработчик. Итого, у нас есть абстрактная железка, которая умеет читать RFID-метки, и абстрактный софт, который умеет преобразовывать данные в нужный нам формат. Назовем их RFIDSensor и RFIDParser соответственно. Как это отобразить в System Composer? Можно удалить компонент RFIDReader и вместо него поставить два компонента, но так лучше не делать, так мы потеряем читаемость архитектуры. Вместо этого зайдем внутрь RFIDReader и добавим 2 новых компонента: Отлично, теперь перейдем к оповещению пользователя. Каким образом система оповестит пользователя о том, что ему запрещен или разрешен доступ к помещению? Человек, воспринимает лучше всего звуки и что-то мигающее. Поэтому можно выдать некий звуковой сигнал, что бы пользователь обратил внимание, и помигать светодиодом. Добавим соответствующие компоненты в UserNotify: Мы создали архитектуру нашей системы, но в ней что-то не так. Что же? Посмотрим на имена соединений. InBus и OutBus — не совсем нормальные имена, которые бы помогали разработчику. Их надо переименовать: Итак, мы посмотрели на то как применяются методы системной инженерии в самом грубом приближении. Появляется вопрос — зачем их применять вообще? Система примитивная, и кажется, что проделанная работа излишняя. Можно было бы сразу писать код, проектировать БД, писать запросы или паять. Проблема заключается в том, что если не продумать систему, не понять как ее компоненты связаны друг с другом, то интеграция компонентов системы будет идти долго и достаточно болезненно.

Главный вывод из этой части такой: Применение методов системной инженерии и моделирования архитектур при разработке систем позволяет сократить затраты на интеграцию компонентов и повысить качество разрабатываемой системы.