«Сделаем робота, который не поедет при потере связи» — хорошая тема, но ещё не модуль. Непонятно, что такое «потеря», кто её измеряет, какая команда считается движением и что увидит наблюдатель. Модуль начинается там, где на эти вопросы можно ответить без догадки.
Четыре вопроса до выбора детали
- Какая одна наблюдаемая функция нужна?
- Где проходит граница ответственности модуля?
- Что сознательно не входит в его задачу?
- Каким наблюдением подтвердим результат?
Учебный пример без привода
Разберём условный модуль «разрешение команды движения» в симуляции или на стенде с физически отключённым исполнительным контуром. Входы: arm_request, link_ok, zone_ok. Выходы: permit_motion, block_reason. Правило: при невалидном или отсутствующем входе permit_motion = false.
| Элемент | Направление | Валидное состояние | При ошибке |
|---|---|---|---|
arm_request |
вход | явно задано | запрет |
link_ok |
вход | свежая связь | запрет |
zone_ok |
вход | зона разрешена | запрет |
permit_motion |
выход | все условия истинны | false |
Тест подтверждает только логику выбранной модели входов в конкретной версии симуляции. Он не подтверждает физический привод, надёжность связи или безопасность машины.
Карточка модуля
Название / версия / статус:
Одна задача:
Не входит в задачу:
Требование с условиями и критерием:
Интерфейс: входы, выходы, единицы, тайм-аут:
Состояния: исходное / разрешённое / заблокированное / ошибка:
Ограниченный тест и стоп-события:
Артефакт результата:
Что вывод НЕ доказывает:Контракт — не разъём. Он описывает встречу механики, энергии, данных и отказов. До такого контракта корректно говорить «идея модуля», а не «совместимое дополнение для платформы».