Обзор ключевых компонентов «автономной информационной системы логистики» (ALIS) унифицированного ударного истребителя F-35. Подробный разбор «блока обеспечения боевого применения» и четырёх его ключевых компонентов: 1) человеко-системный интерфейс, 2) исполнительно-контролирующая система, 3) бортовая иммунная система, 4) система авионики. Некоторые сведения относительно программно-аппаратного обеспечения истребителя F-35 и относительно инструментария, который используется для его бортового программного обеспечения. Приведёно сравнение с более ранними моделями боевых истребителей, и также указаны перспективы для дальнейшего развития армейской авиации.
Сап, котятки.
Я пришёл рассказать о проекте UAVCAN — новом сетевом стандарте для организации взаимодействия узлов и компонентов современных транспортных средств с высоким уровнем автономности/автоматизации. Название является акронимом от Uncomplicated Application-level Vehicular Computing And Networking (несложные бортовые сети и коммуникации уровня приложения).
В этой публикации объясняется текущее положение дел и тренды в области сложных бортовых систем, существующие и грядущие проблемы, как мы их решаем и каких успехов добились. Во второй части наши коллеги из Университета Иннополис подробно осветят практическую сторону внедрения UAVCAN на примере конкретных проектов.
Первый блин проекта был заложен в 2014-м. С самого начала это был эксперимент в минимализме: возможно ли в разработке сложных распределённых бортовых систем опираться на мощные абстракции, избегая при этом роста сложности реализации и связанных с ним трудностей валидации и верификации.
Мы наблюдаем быстрый рост сложности бортовых систем, связанный с развитием функциональных возможностей транспортных средств (особенно беспилотных) в целом, и систем автоматического управления в частности.
Заслуженно распространена точка зрения, что типичный разработчик высокоуровневого прикладного ПО настолько свыкся с доступностью системных ресурсов и мягкостью требований реального времени, что ожидать от него оптимизации кода в угоду снижения ресурсоёмкости приложения можно лишь в крайних случаях, когда этого прямо требуют интересы бизнеса. Это и логично, ведь в задачах прикладной автоматизации самым дорогим ресурсом остаётся ресурс человеческий. Более того, снижение когнитивных затрат на возню с байтами оставляет внимание разработчика свободным для задач первоочередной важности, таких как обеспечение функциональной корректности программы.
Редко когда речь заходит об обратной проблеме, имеющей место в куда более узких кругах разработчиков встраиваемых систем, включая системы повышенной отказоустойчивости. Есть основания полагать, что ранний опыт использования MCS51/AVR/PIC оказывается настолько психически травмирующим, что многие страдальцы затем продолжают считать байты на протяжении всей карьеры, даже когда объективных причин для этого не осталось. Это, конечно, не относится к случаям, где жёсткие ценовые ограничения задают потолок ресурсов вычислительной платформы (микроконтроллера). Но это справедливо в случаях, где цена вычислительной платформы в серии незначительна по сравнению со стоимостью изделия в целом и стоимостью разработки и верификации его нетривиального ПО, как это бывает на транспорте и сложной промышленной автоматизации. Именно о последней категории систем этот пост.
Сегодня я публикую перевод доклада «An Examination of Open System Architectures for Avionics Systems– An Update» сделанного Joyce L. Tokar, PhD, Pyrrhus Software, LLC, в марте 2017.
Признавая необходимость доступных и эффективных решений для развития систем авионики, Министерство обороны США (Department of Defense, DoD ) в указаниях по повышению эффективности военных расходов (Better Buying Power 3.0, BBP), Инструкции 5000.02 и Руководстве по оборонным закупкам (Defense Acquisition Guidebook, DAG) призывает к использованию решений на базе Систем с отрытой архитектурой (Open System Architecture, OSA ). Цели руководства и указаний - избежать привязки к одному поставщику, сделать доступными развитие возможностей и /продвижение инноваций. В настоящее время осуществляются несколько инициатив по разработке стандартов OSA для использования в системах военной авионики. В этой статье будут рассмотрены три таких направления: Управление беспилотными системами (UxS ), Архитектура сегмента управления (UCS ), инициатива Открытые системы управления полетом (Open Mission Systems, OMS ) и реализация Перспективной среды авиационных бортовых систем (FACE) выполненная открытой группой (Open Group). Эта статья начнется с уточнения определения систем с открытой архитектурой в понимании Министерства обороны США. Далее будет краткое описание этих трех стандартов OSA, мероприятий, которые проводятся в соответствии с указаниями Министерства обороны США. Документ затем представит анализ этих OSA на основе рекомендаций Министерства обороны США. И наконец, в документе будет обобщено состояние этих OSA и даны рекомендации для дальнейшей работы.