Практические стратегии для перехода на модельно-ориентированное проектирование встроенных приложений

Введение 

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

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

Эта статья содержит три основных раздела:

1. Организационные трудности.
2. Стратегия по внесению изменений.
3. План перехода для производственных процессов и инструментов.

В разделе «Организационные трудности» приводятся ответы на вопросы:

• Что модельно-ориентированное проектирование значит для сотрудников организации?
• Предполагается ли обучение?
• Будет ли необходимо осуществление новых видов работ?
• Следует ли реорганизовывать персонал, чтобы получить все преимущества модельно-ориентированного проектирования?
• Как входные и выходные параметры организации, разрабатывающей встроенные системы, изменятся при переходе на модельно-ориентированное проектирование?

В разделе «Стратегия по внесению изменений» рассматривается оптимальный метод перехода на модельно-ориентированное проектирование. Он является поэтапным и включает определение структурированной системы критериев для выбора первого проекта. Для этого необходимо получить ответы на следующие вопросы:

• Какую проблему необходимо решить?
• С какого проекта следует начать?
• Какой возврат инвестиций (ROI) необходим, чтобы подтвердить эффективность модельно-ориентированного проектирования?
• Как снизить риски при переходе?
• Как эффективно осуществить перенос большой существующей базы кодов?
• Каков следующий шаг после первоначального проекта?

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

Организационные трудности 

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

критически важна. Необходимость вызвана следующими тремя факторами:

1. Новые инженерные задачи.
2. Акцент на составление требований и проектирование.
3. Интеграция процессов и инструментов.

Новые инженерные задачи.

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

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

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

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

Акцент на составление требований и проектирование. 

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

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

Интеграция процесса и инструментов.

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

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

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

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

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

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

Стратегия по внесению изменений 

План изменений 

Введение модельно-ориентированного проектирования должно сопровождаться необходимыми изменениями процесса, которые могут включать в себя принятие таких стандартов, как AUTOSAR, ISO 26262 и DO-178C, разработку передовых технологий (например, гибридных электрических транспортных средств и ветроэнергетических систем) или инициативу непрерывного улучшения.

Определение решаемой задачи 

Перед переходом на модельно-ориентированное проектирование необходимо иметь полное понимание неэффективности и убыточности текущего процесса и организации. Необходимо ввести показатели, чтобы поставить цели, количественно рассчитать неэффективность и определить ключевые области, специфические стратегии и инструменты.

Часто число детализированных показателей текущего процесса и организации ограничено. В таких случаях промышленные показатели служат хорошей отправной точкой для определения ключевых областей, на которых следует сконцентрировать улучшение процесса. Известны публикации, в которых приводится описание типичных промышленных показателей [2 – 4]. Одно из исследований показывает, что основной источник затруднений и связанных с этим задержек во всех отраслях промышленности — исправление ошибок в спецификации и верификация разработки. Согласно другому исследованию, 60 % дефектов вносятся в спецификацию, причем 55 % этих дефектов не обнаруживаются до стадии тестирования, что приводит к неэффективному проектированию и отладке требований инженерами по тестированию и настройке. Относительная стоимость исправления ошибок на поздних стадиях процесса разработки представлена в [2]. Зачастую имеются другие показатели неэффективности процесса, такие как время, которое тратят инженеры по настройке на отладку программного обеспечения контроллеров.

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

Выбор проекта с подходящим уровнем сложности и технологичности 

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

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

Поэтапный переход для снижения рисков.

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

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

 Этап 1. Разработка начального плана перехода 

Цель этого этапа состоит в определении инструментов и функциональных возможностей, необходимых для выполнения требований приложения, улучшения процесса и понимания того, как инструменты интегрируются со связанными элементами для разработки. Эта стадия обычно начинается с формального обучения работе с инструментами для понимания их возможностей. Следующий шаг состоит в привязке требований по приложениям и процессам к специфическим инструментам и функциональным возможностям, необходимым для их выполнения. Последний шаг — применить полученные знания на практике, осуществив процесс разработки с эталонной моделью. Данный этап обычно осуществляется посредством разработки простой модели, генерации кода из модели, компиляции кода и загрузки кода на целевое устройство. Всегда доступная поддержка производителей инструментов сильно снижает время, необходимое на обучение. Эта стадия также демонстрирует возможность использования инструментов поддержки построения моделей для любого последующего масштабного внедрения. Результатом этапа является начальный план перехода, используемый для последующего масштабированного внедрения сначала одного компонента, а затем и всего приложения.

Этап 2. Внедрение компонента 

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

Этап 3. Внедрение всего приложения 

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

Этап 4. Оптимизация и расширение внедрения 

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

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

Выбор подходящих имеющихся инструментов для осуществления перехода 

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

Как было замечено в статье «Best Practices for Establishing a Model-Based Design Culture» [1], переход предоставляет огромные возможности для обучения. Во встроенных системах управления, разрабатываемых годами разными авторами, вполне обычны сегменты кода, которые не до конца понятны текущим разработчикам. Процесс создания моделей существующих алгоритмов позволяет разработчику глубже понять эти области, повышая при этом ясность, качество и удобство сопровождения.

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

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

•частое изменение или необходимость изменения в будущем;

•проблемы с качеством;

•высокая сложность, трудоемкость сопровождения;

•возможность представления в виде модели.

Компоненты, не удовлетворяющие этим критериям, не дают больших преимуществ при их переводе в модели.

 План перехода для производственных процессов и инструментов 

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

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

Этап составления требований 

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

Разработка выполняемой спецификации как возможность установить формальные требования 

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

Проведение валидации требований перед переходом к рабочему проекту 

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

Взаимодействие с внутренними и внешними клиентами и поставщиками с помощью модели 

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

Модель как источник документации 

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

Этап проектирования 

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

Заблаговременный выбор архитектуры и технологии компонентов 

Архитектура модели и технология, используемая для инкапсуляции компонентов в проекте, влияют на ряд областей, включая производительность моделирования,

скорость генерации кода, эффективность кода, процесс проверки конфигурации и изменений и удобство эксплуатации. Особенности компонентов, таких как ссылки на модель (model reference), элементарные подсистемы (atomic subsystem) и библиотеки, следует учитывать сразу в начале процесса проектирования для получения масштабируемой архитектуры модели, отвечающей текущим нуждам. Например, ссылку на модель следует использовать для компонентов, которые необходимо независимо верифицировать вне модели, которой они принадлежат, или когда есть необходимость генерировать повторно используемую функцию в программном обеспечении.

Внедрение и закрепление стандартов проектирования (например, MAAB) 

Среды для построения моделей обеспечивают высокую гибкость и одновременно с этим предоставляют внешние библиотеки шаблонов проектирования для решения общих задач. При неаккуратном обращении модели могут быстро стать нечитаемыми и неэффективными, снижая эффективность моделирования, генерации кода и передачи информации между участниками проекта. Введение стандартов проектирования позволяет предотвратить создание неэффективных моделей. Они гарантируют, что модель будет пригодна к производству и понятна, и дают возможность избежать общих ошибок проектирования перед переходом к следующему этапу. Начать можно с принятия промышленных стандартов, таких как «Руководство по оформлению автомобильного консультативного комитета MathWorks» (MAAB), которое можно внедрить с помощью ряда автоматизированных проверок. Если требуется обеспечить критичный по безопасности рабочий процесс, следует также рассмотреть правила создания моделей, соответствующих стандартам IEC 61508 или DO-178B. Автоматическая проверка позволяет убедиться в гибкости разработки и эффективности последующей реализации. Стандарты и автоматические проверки основываются на накопленном отраслевом опыте, и на них стоит обратить повышенное внимание.

Внедрение процесса для упрощения повторного использования 

Проектировать следует с учетом возможности повторного использования элементов проекта, но стоит помнить и о способах упрощения повторного использования за счет разделения ресурсов. Это позволит упростить разработку и увеличить ее гибкость. Хотя это лучшая практика с точки зрения здравого смысла, лишь малая группа компаний осуществляет ее, и те, кто это делает, занимают передовые позиции [5]. Ведущие компании-производители, определяемые по их успеху в достижении ряда инженерных целей, объединяют подготовку и верификацию разработок для повторного использования в своих рабочих процессах. В этих компаниях также предпочитают разделять ресурсы для ускорения разработок при повторном использовании. Для упрощения повторного использования в модельно-ориентированном проектировании могут использоваться следующие стратегии:

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