Этот сайт использует файлы cookies. Продолжая просмотр страниц сайта, вы соглашаетесь с использованием файлов cookies. Если вам нужна дополнительная информация, пожалуйста, посетите страницу Политика файлов Cookie

Прямой эфир

Русский

English

Войти / Регистрация

Cryptocurrencies: 8366 / Markets: 114258

Market Cap: $ 2 577 854 368 939 / 24h Vol: $ 71 713 513 748 / BTC Dominance: 59.94172130463%

Н Новости

Проектирование архитектуры в нотации ArchiMate с использованием ИИ. Часть 2

“Процесс проектирования любой системы, предназначенной для решения определенных задач, начинается с определения того, что надо спроектировать.”, Крэг Ларман (Craig Larman).

Всем привет! Меня зовут Владимир Зуев, я руководитель разработки JAVA-практики в компании Axenix. Сегодня я хочу представить новую часть из цикла статей о нотации ArchiMate. В прошлой части мы познакомились с ArchiMate и начали проектировать систему управления беспилотным грузовым автотранспортом для междугородних перевозок. В этой части мы продолжим выполнение данной задачи.

Полностью разделяю мнение Крэга Лармана, автора книги «Применение UML 2.0 и шаблонов проектирования»: нельзя приступать к проектированию (а значит, и к рассмотрению бизнес-слоя), не имея чёткого понимания того, что же мы хотим получить. Поэтому сегодня мы попытаемся получить ответ на этот вопрос. В данной части работы акцент будет сделан на сбор, систематизацию и осмысление требований. Для этого мы подробно разберём требования к системе, составим перечень прецедентов использования c использованием обратного инжиниринга требований, а также сформируем техническое задание. Для решения всех задач будем использовать ИИ.

Осмысление требований

Cбор и систематизация требований при разработке информационной системы - это фундамент, на котором строится весь проект. Ошибки на этом этапе самые дорогие. Закон Бёма (Boehm's Law) гласит, что стоимость исправления ошибки экспоненциально растет по мере продвижения проекта:

ошибка в требованиях, найденная на этапе анализа, стоит 1 условную единицу;
найденная на этапе проектирования — уже 3–6 единиц;
на этапе тестирования — 10–20 единиц;
в работающей системе (после внедрения) — 60–100 единиц и выше.

Так что гораздо дешевле потратить немного времени на уточнение требований в начале, чем переписывать систему после релиза.

Основная этапа определения требований – найти и зафиксировать что же должна делать система. В разработке информационных систем требования принято делить на три основные категории:

функциональные — конкретные действия системы (формируются через модель прецедентов);
нефункциональные — требования к надежности и качеству (влияют на архитектуру);
ограничения — жесткие рамки, которые система не может нарушать (их анализ порождает новые функциональные требования).

В идеальном мире функциональные требования должны формироваться из прецедентов. Прецеденты важны, потому что они связывают требования с реальными нуждами — каждый прецедент показывает, зачем системе нужна та или иная функция. Один прецедент как правило порождает несколько функциональных требований (кнопка, связь, алгоритм торможения, индикация, запись в лог, отказоустойчивость и т.д).

В кастомной разработке часто встречается другой подход - вы получаете от заказчика уже готовый список требований — часто в виде таблиц, нормативных ссылок или длинного текста. Особенно часто это встречается в государственных или крупных корпоративных проектах). И вам нужно обратным ходом восстановить прецеденты, чтобы:

понять логику заказчика;
проверить полноту сценариев;
подготовить основу для тестирования.

Описанный метод называется «обратный инжиниринг требований» (Requirements Reverse Engineering) или «извлечение прецедентов из требований» (Use Case Discovery from Requirements).

Поэтому в данной работе мы пойдем именно этим путем - на основе требований выделим прецеденты. В основном, это функциональные требования, указывающие на то, что должна делать система. Однако остальные типы тоже могут быть связаны с прецедентами. В процессе проработки прецедентов так же осуществляется уточнение требований. Требования в основном формулируются при описании прецедентов, но в нашем случае существует нормативно-правовая база. Так что переходим к анализу имеющихся исходных данных, а потом на их основе сформируем список прецедентов.

Анализ нормативных документов

Как было сказано в первой части, уже вышел проект закона, полное название которого звучит так: Федеральный закон «О высокоавтоматизированных транспортных средствах и о внесении изменений в отдельные законодательные акты Российской Федерации» (ВАТС).

Закон о ВАТС закрепит права и ответственность участников движения при эксплуатации беспилотных автомобилей и заменит собой все временные регламенты.

Попробуем проанализировать проект ФЗ на предмет важных требований, которые необходимо учитывать при разработке системы управления и мониторинга. Полный текст проекта ФЗ можно найти на сайте ОАО «Научно-исследовательский институт автомобильного транспорта». Первая мысль, которая возникает после открытия файла – “Как много букв…”.

Попробуем ускорить дело, проанализировав файл с помощью GenIA. Загрузим файл проекта в GenAI и выполним следующий промпт:

Проанализируй требования из PDF файла. Приведи список требований к оператору беспилотной грузовой перевозки

Ответ GenAI:

На основе анализа представленного проекта Федерального закона «О высокоавтоматизированных транспортных средствах...», ниже приведен сводный перечень требований и обязанностей, которые законопроект возлагает на оператора сервисного обслуживания (именно этот субъект правоотношений выполняет функции, схожие с оператором беспилотной грузовой перевозки в части контроля за техническим состоянием и дистанционного взаимодействия с ВАТС).

Следует учитывать, что законопроект разделяет понятия «водитель» (лицо в салоне, активирующее систему) и «оператор сервисного обслуживания» (юрлицо/ИП, осуществляющее дистанционный контроль, активацию режимов и ремонт). Для целей беспилотной грузовой перевозки, где водитель в кабине может отсутствовать (ч. 2 ст. 12), именно оператор сервисного обслуживания становится ключевым субъектом обеспечения безопасности движения.

1. Организационно-правовые и лицензионные требования

№	Требование	Основание в тексте PDF
1.1	Наличие лицензии. Деятельность по сервисному обслуживанию ВАТС подлежит обязательному лицензированию.	Ст. 15, ч. 3
1.2	Включение в Реестр. Оператор должен быть включен в Реестр операторов сервисного обслуживания Единой автоматизированной информационной системы ВАТС.	Ст. 20, ч. 2
1.3	Квалификация персонала. Наличие в штате техников-мехатроников, соответствующих установленным квалификационным требованиям и внесенных в Единый реестр техников-мехатроников.	Ст. 2 (определение), Ст. 7 п. 11, Ст. 20 ч. 3
1.4	Наличие производственно-технической базы. Соответствие пунктов сервисного обслуживания установленным требованиям к зданиям, оборудованию и программно-аппаратным средствам.	Ст. 2 (определение), Ст. 15 ч. 3

2. Функциональные обязанности при эксплуатации (управление движением)

№	Требование	Основание в тексте PDF
2.1	Активация и дезактивация режима. Исключительное право (и обязанность при необходимости) осуществлять активацию и дезактивацию беспилотного (автоматизированного) режима движения.	Ст. 11, Ст. 13 п. 13
2.2	Дистанционное управление после дезактивации. При отключении автоматического режима (например, при выезде из ОДД или нештатной ситуации) оператор обязан взять управление на себя или обеспечить безопасную остановку.	Ст. 11, Ст. 13 п. 14
2.3	Контроль среды штатной эксплуатации (ОДД). Запрет активации и обеспечение прекращения автоматического движения, если ТС выходит за пределы установленной среды штатной эксплуатации (участка дороги, погодных условий, для которых сертифицирована система).	Ст. 25, ч. 5
2.4	Реагирование на нештатные ситуации. При получении сигнала от системы о неисправности или ДТП техник-мехатроник обязан: • Деактивировать режим автоматического управления. • Установить связь с находящимися в ТС людьми. • Принять меры для обеспечения безопасности движения. • Организовать прекращение эксплуатации при угрозе безопасности.	Ст. 26 (стр. 49, ч. 4)
2.5	Проверка и настройка систем. Проведение плановых и внеплановых проверок работоспособности, настройки и корректировки режимов автоматизированной системы вождения (как дистанционно, так и непосредственно).	Ст. 11, Ст. 25 ч. 5
2.6	Информирование пользователя. При ручном режиме управления (если в ТС есть водитель-испытатель) оператор обязан незамедлительно извещать его о любых сбоях в работе автоматики.	Ст. 25, ч. 5

3. Технические и программные требования

№	Требование	Основание в тексте PDF
3.1	Обновление ПО. Обеспечение своевременной установки обновлений программного обеспечения автоматизированной системы вождения (в соответствии с регламентом изготовителя и требованиями информационной безопасности).	Ст. 11, Ст. 12 ч. 11
3.2	Соблюдение регламентов изготовителя. Проведение технического обслуживания и ремонта строго в соответствии с нормами, правилами и процедурами, установленными изготовителем ВАТС (сервисная книжка).	Ст. 15, ч. 2
3.3	Ведение учета. Внесение записей о проведенных сервисных обслуживаниях в сервисную книжку и передача сведений в Единую информационную систему ВАТС.	Ст. 25, ч. 5, Ст. 26 (стр. 49)
3.4	Обеспечение связи. Обеспечение функционирования двусторонней голосовой связи с ВАТС и кнопки экстренного вызова (ЭРА-ГЛОНАСС).	Ст. 12, ч. 6, Ст. 13 п. 9

4. Требования информационной безопасности и отчетности

№	Требование	Основание в тексте PDF
4.1	Конфиденциальность. Запрет на передачу информации, полученной в результате рабочей деятельности, третьим лицам без согласия обладателя.	Ст. 25, ч. 6 п. 5
4.2	Передача данных в госорганы. Обязанность передавать данные о ДТП, деактивациях систем, неисправностях и иную информацию в Единую автоматизированную информационную систему ВАТС.	Ст. 20, Ст. 25 ч. 5
4.3	Защита от кибератак. Обеспечение мер защиты от неправомерного доступа, перехвата управления и радиоэлектронного подавления.	Ст. 24
4.4	Прекращение эксплуатации. При получении уведомления от изготовителя о запрете эксплуатации (отзывная кампания) или выявлении критической неисправности, оператор обязан немедленно прекратить эксплуатацию ТС.	Ст. 25, ч. 5

5. Ответственность оператора

№	Вид ответственности	Основание в тексте PDF
5.1	За качество работ. Оператор несет ответственность за качество технического обслуживания и ремонта, а также за соблюдение технологии обновления ПО.	Ст. 22, ч. 6 (стр. 53)
5.2	За безопасность. Ответственность за нарушение правил эксплуатации ВАТС в зоне своей ответственности (включая активацию режима вне ОДД).	Ст. 21-22
5.3	За непредоставление сведений. Ответственность за непредставление или искажение сведений, подлежащих внесению в Единую информационную систему ВАТС.	Ст. 22, ч. 6

Резюме для оператора грузовой перевозки

Согласно данному законопроекту, оператор беспилотной перевозки (в терминологии документа — оператор сервисного обслуживания) фактически выполняет роль внешнего экипажа для беспилотного грузовика. Он должен:

Иметь лицензию и аттестованного техника-мехатроника.

Дистанционно разрешать старт и принудительно останавливать машину в случае сбоя.

Следить за тем, чтобы грузовик не покинул разрешенную зону эксплуатации (геозону).

Оперативно обновлять защищенное программное обеспечение.

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

Какие требования предъявляются к интерфейсу пользователя?

Ответ GenAI:

Согласно проекту Федерального закона, требования к интерфейсу пользователя (в тексте документа он именуется «Блок интерфейса пользователя в салоне высокоавтоматизированного транспортного средства») подробно изложены в Статье 12, частях 4, 5 и 6.

Ниже приведен структурированный перечень обязательных требований к данному блоку, который должен быть установлен в салоне транспортного средства.

1. Информационные функции (что должен показывать и сообщать)

Блок интерфейса обязан обеспечивать информирование пользователя (пассажира или водителя-испытателя) о следующих параметрах и событиях:

№	Функция / Требование
1.1	Идентификация ТС: Индикация информации о марке, модели и государственном регистрационном знаке ВАТС.
1.2	Построение маршрута: Возможность задания пользователем пункта назначения и маршрута к нему.
1.3	Запуск двигателя: Возможность запуска двигателя пользователем (опционально, если это предусмотрено конструкцией).
1.4	Статус движения: Информирование о начале движения и отслеживание движения по маршруту.
1.5	Дорожная обстановка: Оперативное информирование о дорожно-транспортной ситуации.
1.6	Изменение маршрута: Возможность изменения маршрута пользователем в пути и уведомление о таком изменении.
1.7	Статус автопилота: Информирование о фактическом статусе функционирования автоматизированной системы вождения (активна/неактивна/ошибка).
1.8	Предупреждение о выходе из ОДД: Аварийная сигнализация о том, что система выходит за пределы установленной среды штатной эксплуатации (например, покидает разрешенную геозону или попадает в неподходящую погоду).
1.9	Отмена поездки: Информирование о невозможности продолжения перевозки до пункта назначения с указанием причин.
1.10	Завершение поездки: Информирование о достижении места назначения.

2. Органы управления и элементы физического интерфейса

Блок интерфейса должен содержать конкретные физические (или четко обозначенные виртуальные) элементы управления:

№	Элемент	Описание и требования
2.1	Кнопка «Экстренный вызов»	Должна иметь конструктивную защиту от непреднамеренного нажатия. Обеспечивает двустороннюю голосовую связь с экстренными службами (система ЭРА-ГЛОНАСС).
2.2	Кнопка вызова оператора	Обеспечивает двустороннюю голосовую связь с оператором сервисного обслуживания (диспетчером/техником-мехатроником).
2.3	Индикаторы состояния	Визуальное отображение состояния устройства вызова экстренных служб (например, готовность, ошибка, связь).
2.4	«Красная кнопка»	Орган аварийного отключения. Предназначена для экстренного отключения автоматизированной системы вождения и остановки транспортного средства.

3. Специальные требования доступности (Инклюзивность)

Отдельное внимание уделяется доступности интерфейса для маломобильных групп населения:

№	Требование
3.1	Адаптивный человеко-машинный интерфейс: Интерфейс должен обеспечивать взаимодействие с людьми с ограниченными возможностями.
3.2	Способы взаимодействия: Взаимодействие должно быть реализовано посредством: • Визуальных сообщений; • Голосовых сообщений; • Сенсорных экранов с обратной связью (тактильная отдача).

4. Общие функциональные требования безопасности

Помимо конкретных кнопок, интерфейс в целом должен поддерживать выполнение следующих критических сценариев, заложенных в логику автоматизированной системы (Ст. 13):

Распознавание сигналов регулировщика (ч. 2 п. 6) — интерфейс должен корректно интерпретировать и отображать статус «внимание, ручное управление/остановка по требованию».
Уведомление о переходе на ручное управление (ч. 2 п. 12) — при воздействии водителя на органы управления (если они есть) интерфейс должен отобразить переход в ручной режим.
Уведомление о безопасной остановке (ч. 2 п. 14) — при деактивации режима оператором сервисного обслуживания интерфейс должен проинформировать пассажира о возможности безопасно покинуть ТС.

Итак, мы получили список требований, сгруппированных по категориям. Теперь мы знаем требования, зафиксированные в нормативных документах.

Отдельно в проекте ФЗ закреплен блок мониторинга и дистанционной поддержки, в соответствии с которым контроль состояния ВАТС и параметров функционирования АСВ осуществляется в реальном времени при непосредственном участии оператора дистанционной поддержки. В частности, он может активировать или деактивировать АСВ, корректировать маршрут, запускать манёвр минимального риска и ограничивать движение. Оператор также обязан выполнять требования контролирующих органов об ограничении или приостановке эксплуатации ВАТС, а в случае ДТП — оперативно информировать ГИБДД и вызывать соответствующие службы при наличии пострадавших.

Анализ требований

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

Необходимо систематизировать требования из загруженного PDF, а также разделить их по категориям:
- функциональные
- нефункциональные
- ограничения

Ответ GenAI:

Ниже представлена систематизация ваших требований по трём категориям. Повторения устранены, формулировки приведены к краткому тезисному виду.

Функциональные требования (что должна делать система)

Управление режимами движения:

Активация и дезактивация автоматизированного режима движения.
Дистанционное управление ТС после дезактивации автопилота (в нештатных ситуациях).
Экстренное отключение автоматизированной системы вождения и остановка ТС («красная кнопка»).

Контроль и мониторинг:

Контроль нахождения ТС в разрешённой среде эксплуатации (геозона, погодные условия). Запрет активации или прекращение движения при выходе за границы.
Реагирование на нештатные ситуации: деактивация режима, связь с находящимися в ТС людьми, меры по обеспечению безопасности, прекращение эксплуатации при угрозе.

Информирование пользователя (интерфейс в салоне):

Отображение марки, модели и госномера ТС.
Задание пункта назначения, построение и изменение маршрута.
Информирование о начале движения, ходе поездки, прибытии.
Отображение статуса автопилота (активен/неактивен/ошибка).
Аварийная сигнализация при выходе из разрешённой среды эксплуатации.
Сообщение о невозможности завершить поездку с указанием причин.
Информирование о дорожно-транспортной ситуации.
Уведомление о переходе на ручное управление.
Уведомление о безопасной остановке (возможность покинуть ТС).

Связь и вызовы:

Обеспечение двусторонней голосовой связи с экстренными службами (кнопка «Экстренный вызов» с защитой от случайного нажатия).
Обеспечение двусторонней голосовой связи с оператором сервисного обслуживания.
Отображение состояния устройства вызова экстренных служб (готовность, ошибка, связь).

Обслуживание и учёт:

Проведение плановых и внеплановых проверок работоспособности, настройка автоматизированной системы вождения.
Внесение записей о сервисных обслуживаниях в сервисную книжку.
Передача сведений о ДТП, деактивациях, неисправностях в Единую автоматизированную информационную систему ВАТС.

Доступность:

Обеспечение взаимодействия с людьми с ограниченными возможностями здоровья через визуальные, голосовые сообщения и сенсорные экраны с тактильной обратной связью.

Нефункциональные требования (качества и атрибуты)

Безопасность (эксплуатационная):

Недопущение эксплуатации при наличии запрещающих движение неисправностей.
Немедленное прекращение эксплуатации при выявлении технических неисправностей, создающих угрозу безопасности.
При получении уведомления от изготовителя о запрете эксплуатации (отзывная кампания) или критической неисправности — немедленная остановка.

Информационная безопасность:

Защита от неправомерного доступа, перехвата управления и радиоэлектронного подавления.
Защита данных от уничтожения, изменения или распространения.
Постоянный контроль уровня защищённости информации.
Конфиденциальность: запрет передачи информации третьим лицам без согласия обладателя.

Надёжность и качество:

Соответствие технического состояния ТС требованиям законодательства РФ о безопасности дорожного движения.
Обеспечение своевременной установки обновлений ПО (в том числе для устранения киберугроз) по регламенту изготовителя.
Соблюдение порядка обновления ПО, утверждённого производителем.
Качество работ по ТО и ремонту, соблюдение технологий обслуживания ПО.

Эксплуатационная пригодность:

Обеспечение функционирования двусторонней голосовой связи и кнопки экстренного вызова.
Наличие в штате техников-мехатроников с соответствующей квалификацией (внесённых в Единый реестр).

Ограничения (жёсткие рамки, которые система не может нарушать)

Правовые и лицензионные:

Наличие лицензии на деятельность по сервисному обслуживанию ВАТС.
Включение оператора в Реестр операторов сервисного обслуживания Единой автоматизированной информационной системы ВАТС.
Обязательное оформление ОСАГО в соответствии с ФЗ № 40-ФЗ.

Организационно-технические:

Наличие производственно-технической базы, соответствующей требованиям к зданиям, оборудованию и программно-аппаратным средствам.
Проведение ТО и ремонта строго в соответствии с нормами и процедурами изготовителя ВАТС (сервисная книжка).
Обязательная передача данных в госорганы (Единую автоматизированную информационную систему ВАТС).

Эксплуатационные запреты:

Запрет активации автоматического режима при выходе ТС за пределы установленной среды штатной эксплуатации.
Запрет на передачу информации третьим лицам без согласия обладателя.
Недопущение эксплуатации при наличии неисправностей, запрещающих движение.

Ответственность (юридические ограничения):

Ответственность оператора за качество ТО, ремонта и соблюдение технологии обновления ПО.
Ответственность за нарушение правил эксплуатации ВАТС в зоне своей ответственности.
Ответственность за непредоставление или искажение сведений, подлежащих внесению в Единую информационную систему.

Мы систематизировали требования, разбросанные по разным разделам ВАТС. Такой вид прекрасно подходит для технического задания, по сути являясь основой данного документа.

Функциональные требования:

управление автопилотом (активация/деактивация/экстренная остановка);
контроль геозоны;
информирование пассажира (статус, маршрут, предупреждения);
двусторонняя связь (экстренная и с оператором);
ведение учёта обслуживания;
передача данных в госорганы;
доступность для людей с ограниченными возможностями здоровья (ОВЗ).

Нефункциональные требования:

защита от кибератак и перехвата управления;
конфиденциальность данных;
своевременное обновление программного обеспечения;
квалифицированный персонал;
контроль уровня защищённости;
немедленная остановка при угрозе.

Ограничения:

наличие лицензии и включение в реестр;
соответствие базе требованиям законодательства;
привязка к регламентам изготовителя;
обязательное страхование гражданской ответственности (ОСАГО);
юридическая ответственность оператора.

С требованиями разобрались, теперь разберем ограничения.

Ограничения и границы задачи

Основным ограничением, которое необходимо учитывать при разработки нашей системы является тот факт, что транспортное средство является источником повышенной опасности. Этот факт диктует особые требования к надежности системы. Более того, согласно ВАТС, разработчик ПО несет ответственность за ДТП, в случае если оно было совершено в результате программной ошибки. В проекте ФЗ появилась важная деталь – определена ответственностью за ДТП с беспилотным транспортом. Если сейчас в случае ДТП могут быть виноваты только водители или производители, то с принятием ФЗ о ВАТС круг ответственных лиц существенно расширится. В том числе ответственность будет нести и оператор. Согласно проекту ФЗ оператор дистанционной поддержки будет нести ответственность в случае неисполнения им операторских обязанностей.

Кроме того, в текущей геополитической обстановке периодическое отсутствие мобильного интернета в отдельных района стало нормой, а спутниковая навигация нельзя часто дает сбои. Обычный путь из дома на работу, согласно встроенной навигации, может выглядеть следующим образом.

Если же ориентироваться по навигатору при перемещении между регионами, то можно обнаружить, что определяемые координаты могут отличаться от реального местоположения на десятки километров.

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

Если полагаться только на спутниковую навигацию, до данное требование не выполнимо в секущих условиях. Из этого ограничения вытекает новое функциональное требование – определение геоположения на основе визуальной информации.

К границам задачи можно отнести роль оператора беспилотной грузовой перевозки. В данной работе не будет рассматриваться роль оператора инфраструктуры, а также управление непосредственно транспортной единицей. Такие системы уже существуют и успешно развиваются.

Дальнейшее проектирование будет опираться на функциональные требования. Мы не будем рассматривать юридические аспекты и вопросы безопасности, сконцентрировавшись на функциях системы.

Прецеденты

Прецеденты (варианты использования) — это инструмент, который упрощает формулировку требований для всех заинтересованных лиц. По сути, это рассказы об использовании системы для решения поставленных задач. Прецеденты описывают сценарии взаимодействия между пользователем и системой. На этапе их определения система рассматривается как «чёрный ящик»: мы не пытаемся заглянуть внутрь, а сосредотачиваемся на том, какие задачи должна решать система и какие цели достигать с её помощью.

Итак, выявим перечень прецедентов методом обратного инжиниринга требований. Обычно этот метод выполняется путём анализа и группировки требований, что может занимать значительное время. Использование искусственного интеллекта позволяет ускорить этот процесс — достаточно выполнить следующий промпт:

Определи основных исполнителей для прецедентов в соответствии с полученным списком требований.

Ответ GenAI:

Ниже представлен список основных исполнителей (акторы).

Акторы (исполнители)

Актор	Описание
Пассажир	Лицо, находящееся в ТС (может не иметь навыков управления)
Водитель-испытатель	Лицо, находящееся в ТС, способное взять ручное управление
Оператор сервисного обслуживания	Удалённый оператор (техник-мехатроник), управляющий ТС и обслуживающий его
Изготовитель / Дилер	Ответственный за обновления ПО и отзывные кампании
Экстренные службы	Внешние службы (112, скорая, МЧС, полиция)
Единая информационная система ВАТС	Государственная автоматизированная система сбора данных
Система (автоматика)	Сама автоматизированная система вождения (выполняет действия без участия человека)

Составь список прецедентов для актора «Оператор сервисного обслуживания» в соответствии с полученным списком требований. Другие прецеденты не нужны. Уточнение: В ТС нет ни пассажиров, ни водителя-испытателя.

Ответ GenAI:

Ниже представлен только список прецедентов для актора «Оператор сервисного обслуживания» (техник-мехатроник), где один прецедент покрывает сразу несколько функциональных требований. Прецеденты сгруппированы по функциональным блокам.

Прецеденты оператора сервисного обслуживания (полностью беспилотный автомобиль)

Актор: Оператор сервисного обслуживания (техник-мехатроник)

Уточнение: В ТС нет ни пассажиров, ни водителя-испытателя. Все взаимодействия — только между оператором, системой ТС, внешними службами и госорганами.

Группа 1. Управление движением

UC‑O‑1. Управление автоматизированным режимом

Описание: Оператор управляет включением и выключением автопилота, перехватывает управление при необходимости.