Сконфигурируйте коммуникацию отправителя и получателя в очереди AUTOSAR

При обмене данными с получателем (S-R) в очереди AUTOSAR программные компоненты AUTOSAR считывают и записывают данные в другие компоненты или службы. Данные, отправленные программным компонентом отправителя AUTOSAR, добавляются в очередь, предоставляемую окружением выполнения AUTOSAR (RTE). Вновь полученные данные не перезаписывают существующие непрочитанные данные. Позже программный компонент приемника считывает данные из очереди.

Для реализации обмена данными S-R в очереди, программные компоненты AUTOSAR определяют:

  • Интерфейс отправителя-получателя AUTOSAR с элементами данных.

  • AUTOSAR обеспечивает и требует порты, которые отправляют и получают данные в очереди.

В Simulink®, можно:

  1. Создайте интерфейсы и порты S-R в очереди AUTOSAR с помощью словаря AUTOSAR.

  2. Модель AUTOSAR обеспечивает и требует порты с помощью выходов и входных портов корневого уровня Simulink.

  3. Сопоставьте выходные порты и входные порты с AUTOSAR, обеспечивающими и требующими порты, с помощью редактора Отображения. Установите режимы доступа к данным AUTOSAR на QueuedExplicitSend или QueuedExplicitReceive.

Чтобы смоделировать отправку и прием данных AUTOSAR с помощью очереди, используйте блоки Simulink Send и Receive. Если ваша реализация связи S-R в очереди включает состояния или требует логики принятия решений, используйте Stateflow® чарты. Можно обрабатывать ошибки, возникающие, когда очередь пуста или полна. Можно задать размер очереди. Для получения дополнительной информации смотрите Обзор сообщений Simulink.

Можно симулировать коммуникацию отправитель-получатель (S-R) в очереди AUTOSAR между моделями компонента, например, в симуляции уровня композиции. Отправители и приемники данных могут запускаться с различными скоростями. Несколько отправителей данных могут взаимодействовать с одним приемником данных.

Чтобы начать, можно импортировать компоненты с поставленными в очередь интерфейсами S-R и портами из файлов ARXML в Simulink или использовать Simulink, чтобы создать интерфейсы и порты.

Рабочий процесс Simulink для моделирования отправки и получения в очереди AUTOSAR

Эта процедура описывает общий рабочий процесс моделирования компонентов отправителя и приемника в очереди Autosar в Simulink.

  1. Сконфигурируйте одну или несколько моделей как компоненты отправителя в очереди AUTOSAR, и одну модель как компонент приемника в очереди AUTOSAR. Для каждой модели компонента используйте AUTOSAR Dictionary и редактор Code Mappings, чтобы:

    1. Создайте интерфейс данных S-R и его элементы данных.

    2. Создайте порт отправителя или приемника.

    3. Сопоставьте порт отправителя или приемника с выходным портом Simulink для отправки или входным портом для получения. Установите режим доступа к данным AUTOSAR равным QueuedExplicitSend или QueuedExplicitReceive.

    Для получения примера см. раздел «Настройка компонентов AUTOSAR и Приемника для обмена данными в очереди».

  2. Чтобы реализовать поведение компонента отправителя или приемника в очереди AUTOSAR, используйте блоки Simulink Send и Receive. Для получения дополнительной информации смотрите Обзор сообщений Simulink.

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

    Дополнительные сведения см. в разделе Реализация сообщений отправки и получения в очереди AUTOSAR.

  3. Когда вы создаете модель компонента отправителя или приемника в очереди AUTOSAR:

    • Сгенерированный код C содержит вызовы AUTOSAR Rte_Send_<port>_<DataElement> или Rte_Receive_<port>_<DataElement> API.

      Сгенерированный код обрабатывает состояние вызовов приема сообщений.

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

    • Экспортированные файлы ARXML содержат описание для обмена данными между отправителем и получателем в очереди. Сгенерированный ComSpec для порта в очереди включает тип порта и длину очереди (на основе свойства сообщения Simulink QueueCapacity). В SwDataDefProps сгенерирован для элемента данных порта в очереди, SwImplPolicy установлено в Queued.

  4. Чтобы симулировать коммуникацию отправитель-получатель в очереди AUTOSAR в Simulink, создайте содержащую композицию, систему или модель тестовой обвязки. Включите компоненты отправителя и приемника в очередь в качестве ссылочных моделей.

  5. Чтобы обеспечить логику организации очереди между компонентами отправителя и приемника, можно вставить блок Simulink Queue или логику Stateflow. С помощью блока Queue можно моделировать очередь с определенной емкостью. Если вы соединяете компоненты отправителя и приемника непосредственно, Simulink вставляет очередь по умолчанию с емкостью 1.

    Для примера непосредственного соединения компонентов смотрите модель композиции 1 к 1, используемую в Configure Simulation of AUTOSAR Queued Sender-Receiver Communication.

    Для примеров вставки блока Queue или логики Stateflow между компонентами отправителя и приемника, смотрите Simulate N-to-1 AUTOSAR Queued Sender-Receiver Communication и Simulate Event-Driven AUTOSAR Queued Sender-Receiver Communication.

Сконфигурируйте компоненты отправителя и приемника AUTOSAR для обмена данными в очереди

Этот пример конфигурирует компоненты отправителя и приемника в очереди AUTOSAR в Simulink. В примере используются две модели в папке matlabroot/ help/toolbox/autosar/examples (cd в папку). Если вы копируете файлы в рабочую папку, соедините модели. Чтобы увидеть эти модели, соединенные для симуляции, смотрите Настройте Симуляцию Связи Отправитель-Получатель в ОЧЕРЕДИ AUTOSAR.

  • mAutosarSlSenderSWC1.slx

  • mAutosarSlReceiverSWC.slx

Откройте модель AUTOSAR, которую вы хотите сконфигурировать как компонент отправителя или приемника в очереди. Чтобы создать интерфейс данных S-R и порт отправителя или приемника в очереди:

  1. Откройте словарь AUTOSAR.

  2. Выберите S-R Interfaces. Чтобы создать интерфейс данных S-R, нажмите кнопку Add. Укажите его имя и количество связанных элементов данных S-R. Этот пример использует один элемент данных как в компонентах отправителя, так и в компонентах приемника.

  3. Выберите и разверните новый интерфейс S-R. Выберите DataElements и измените атрибуты элемента данных. Этот рисунок показывает элемент данных DE1 для компонента отправителя.

  4. Разверните узел AtomicComponents и выберите компонент AUTOSAR. Разверните компонент.

  5. Выберите SenderPorts или ReceiverPorts представление и используйте его, чтобы добавить требуемый порт отправителя или приемника. Для каждого порта S-R выберите созданный интерфейс S-R. Для компонента отправителя этот рисунок показывает порт отправителя MsgOut, который использует интерфейс S-R Out1.

  6. Откройте редактор Отображения. Выберите вкладку Inports или Outports и используйте ее для сопоставления входного или выходного порта Simulink с портом S-R в очереди AUTOSAR. Для каждого входного или выходного порта выберите порт AUTOSAR, элемент данных и режим доступа к данным. Установите режим доступа к данным AUTOSAR равным QueuedExplicitSend или QueuedExplicitReceive. В компоненте отправителя этот рисунок показывает выход Simulink MsgOut, который сопоставлен с портом отправителя AUTOSAR MsgOut и DE1 элемента данных, с режимом доступа к данным QueuedExplicitSend.

    При сопоставлении входного порта с портом приемника в очереди AUTOSAR можно использовать представление Property Inspector (или AUTOSAR Dictionary) порта, чтобы изменить его атрибут спецификации связи AUTOSAR (ComSpec) QueueLength. Дополнительные сведения см. в разделе Настройка ComSpecs порта отправителя-получателя AUTOSAR.

Когда вы создаете модель компонента отправителя или приемника в очереди AUTOSAR:

  • Сгенерированный код C содержит вызовы AUTOSAR Rte_Send_<port>_<DataElement> или Rte_Receive_<port>_<DataElement> API. Сгенерированный код обрабатывает состояние отправки и приема вызовов.

  • Экспортированные файлы ARXML содержат описание для обмена данными между отправителем и получателем в очереди. Сгенерированный ComSpec для порта в очереди включает тип порта и длину очереди (на основе свойства сообщения Simulink QueueCapacity). В SwDataDefProps сгенерирован для элемента данных порта в очереди, SwImplPolicy установлено в Queued.

Чтобы реализовать поведение обмена сообщениями компонента отправителя или приемника в очереди AUTOSAR, используйте сообщения Simulink или Stateflow. См. раздел Реализация сообщений отправки и получения в очереди AUTOSAR или Реализация сообщений отправки и получения в очереди AUTOSAR при помощи Stateflow.

Реализация сообщений отправки и приема в очереди AUTOSAR

Чтобы смоделировать поведение компонентов отправителя и приемника в очереди AUTOSAR, этот пример использует:

  • Блоки сообщений Simulink для реализации обмена сообщениями.

  • Диаграммы Stateflow для реализации логики принятия решений.

Этот пример объясняет конструкцию примерных моделей mAutosarSlSenderSWC1.slx и mAutosarSlReceiverSWC.slx. Эти модели расположены в папке matlabroot/ help/toolbox/autosar/examples (cd в папку).

Другие примеры развертывают те же модели отправителя и приемника в строениях обмена сообщениями 1 к 1 и N-to-1. См. «Конфигурирование симуляции связи между отправителем и получателем в очереди AUTOSAR» и «Моделирование связи N-to-1 получателем и получателем в очереди AUTOSAR».

Этот рисунок показывает верхний уровень компонента отправителя в очереди AUTOSAR mAutosarSlSenderSWC1. Модель содержит:

  • Диаграмма Stateflow Turn Signal Generator.

  • Блок Send сообщения Simulink, упакованный в активированную подсистему.

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

Этот рисунок показывает логику, реализованную в Turn Signal Generator график. График имеет четыре состояния - ActivateLeft, DeactivateLeft, ActivateRight, и DeactivateRight. Каждое состояние содержит действия входа, которые присваивают значение данных поворота и устанавливают значение управления сообщением на true. (См. раздел «Связь с диаграммами Stateflow путем отправки сообщений» (Stateflow).) Периодическая синхронизация управляет выходом сообщения.

Этот рисунок показывает верхний уровень компонента приемника в очереди AUTOSAR mAutosarSlReceiverSWC. Модель содержит:

  • Блок Receive сообщения Simulink.

  • Диаграмма Stateflow HMILogic.

Корневой порт MsgIn предоставляет сообщение блоку Receive, которое извлекает значение данных поворота из сообщения. Блок затем выводит значения данных приема и поворота сообщений на диаграмму Stateflow.

Для Receive параметров блоков заданы значения по умолчанию Simulink. Например, Show receive status выбран, Use internal queue очищен, а Value source when queue is empty установлен на Hold last value.

Этот рисунок показывает логику, реализованную в HMILogic график. HMILogic содержит состояния HMIRequestProcessing, LeftTurnSignal, и RightTurnSignal.

  • HMIRequestProcessing получает входы данных о полученном сообщении и поворотном сигнале, устанавливает isNewData флаг, вызывает функцию для обработки данных поворотного сигнала, а затем очищает isNewData флаг. The processRequest функция проверяет полученные данные поворотного сигнала на значения, потенциально установленные отправителем сообщения -- LeftTurnOn, RightTurnOn, LeftTurnOff, или RightTurnOff. На основе полученного значения функция увеличивает или уменьшает переменную счетчика запросов, либо leftTurnReqs или rightTurnReqs. Периодическая синхронизация управляет входом сообщения.

  • LeftTurnSignal и RightTurnSignal каждый содержит состояния Off и On. Они переходят от Off на On на основе значения счетчика запросов leftTurnReqs или rightTurnReqs и временной интервал. Когда счетчик запросов больше нуля, графики задают переменную, либо leftSignalOut или rightSignalOut, к 1. Через временной интервал они переходят назад к Off состояние и задание leftSignalOut или rightSignalOut в 0.

Для примера реализации нескольких компонентов отправителя в очереди в конфигурации N-to-1 обмена сообщениями смотрите модели, используемые в Simulate N-to-1 AUTOSAR Queued Sender-Receiver Communication.

Для примера реализации управляемых событиями сообщений в очереди, смотрите примеры моделей, используемых в Simulate Event-Driven AUTOSAR Queued Sender-Receiver Communication.

Сконфигурируйте симуляцию связи отправитель-получатель в очереди AUTOSAR

Чтобы симулировать коммуникацию отправитель-получатель в очереди AUTOSAR в Simulink, создайте содержащую композицию, систему или модель тестовой обвязки. Включите компоненты отправителя и приемника в очередь в качестве ссылочных моделей.

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

  • Если вы симулируете N-to-1 или событийно-управляемые сообщения, вы обеспечиваете дополнительную логику между моделями компонента отправителя и приемника. Для получения примера смотрите Simulate N-to-1 AUTOSAR Queued Sender-Receiver Communication и Simulate Event-Driven AUTOSAR Queured Sender-Receiver Communication.

Этот пример показывает модель уровня композиции, которая содержит поставленный в очередь отправитель и приемник моделей компонента и реализует коммуникацию 1 к 1. Периодическое таймирование управляет обменом сообщениями. В примере используются три модели в папке matlabroot/ help/toolbox/autosar/examples (cd в папку). Если вы копируете файлы в рабочую папку, соедините модели.

  • mAutosarSlQueuedMsgs_1_1.slx (верхняя часть)

  • mAutosarSlSenderSWC1.slx

  • mAutosarSlReceiverSWC.slx

Модели mAutosarSlSenderSWC1 и mAutosarSlReceiverSWC являются одинаковыми компонентами отправителя и приемника, сконфигурированными в Конфигурирование компонентов отправителя и приемника AUTOSAR для обмена сообщениями в очереди и реализованными в Реализации передачи и приема сообщений в очереди AUTOSAR. Модель уровня состава mAutosarSlQueuedMsgs_1_1 включает их в качестве ссылочных моделей и соединяет порт компонента отправителя MsgOut к порту компонента приемника MsgIn.

Модель верхнего уровня mAutosarSlQueuedMsgs_1_1 предназначен только для симуляции. Можно сгенерировать код AUTOSAR C и файлы ARXML для моделей компонента отправителя и приемника, но не для содержащей модель уровня композиции.

Точно так же можно запустить симуляцию цикл (SIL) для моделей компонента отправителя и приемника, но не для модели уровня композиции.

Симулируйте N-to-1 AUTOSAR в очереди связи между отправителем и получателем

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

Этот пример использует четыре модели в папке matlabroot/ help/toolbox/autosar/examples (cd в папку). Если вы копируете файлы в рабочую папку, соедините модели.

  • mAutosarSlQueuedMsgs_N_1.slx (верхняя часть)

  • mAutosarSlSenderSWC1.slx

  • mAutosarSlSenderSWC2.slx

  • mAutosarSlSenderSWC3.slx

  • mAutosarSlReceiverSWC.slx

Модель уровня состава mAutosarSlQueuedMsgs_N_1 включает три компонента отправителя и компонент приемника в качестве ссылочных моделей. Он соединяет компонент отправителя MsgOut порты к промежуточным MsgJoin логика обработки, которая, в свою очередь, соединяется с компонентом приемника MsgIn порт.

Модели mAutosarSlSenderSWC1 и mAutosarSlReceiverSWC являются одинаковыми компонентами отправителя и приемника, сконфигурированными в Конфигурирование компонентов отправителя и приемника AUTOSAR для обмена сообщениями в очереди и реализованными в Реализации передачи и приема сообщений в очереди AUTOSAR. Второй и третий компоненты отправителя, mAutosarSlSenderSWC2 и mAutosarSlSenderSWC3, аналогичны mAutosarSlSenderSWC1, но реализуйте второй тип входа сообщения для обработки приемником.

Этот рисунок показывает верхний уровень компонента отправителя в очереди AUTOSAR mAutosarSlSenderSWC2. Он содержит диаграмму Stateflow Hazard Signal Generator, который обеспечивает логику для левых поворотных сигналов. График message-line выхода соединяется с исходным портом корня Simulink MsgOut. Соответствующий Hazard Signal Generator график для обработки сигналов поворота вправо появляется в компоненте отправителя mAutosarSlSenderSWC3.

Этот рисунок показывает логику, реализованную в Hazard Signal Generator график. График имеет два состояния - HazardOff и HazardOn. Каждое состояние содержит действия входа, которые присваивают значения данным сообщения и отправляют сообщения. (См. раздел «Связь с диаграммами Stateflow путем отправки сообщений» (Stateflow).) Периодическая синхронизация управляет выходом сообщения.

Между компонентами отправителя и приемника блок Message Merge и блок Queue обеспечивают слияние и построение очередей сообщений.

  • Блок Message Merge объединяет 3 линии сообщений и выводит сообщения в блок Queue.

  • Блок Queue хранит сообщения из 3 линий в очереди, основываясь на порядке прибытия.

    • Емкость очереди устанавливается равной 16 сообщениям.

    • Когда очередь заполнена и приходит сообщение, блок переписывает самое старое сообщение входящим сообщением.

    • Политика сортировки сообщений устанавливается в соответствии с политикой, поддерживаемой Autosar, first-in first-out (FIFO).

Каждый элемент в верхней части очереди отходит, когда нисходящий ReceiverSWC блок готов принять его.

Модель верхнего уровня mAutosarSlQueuedMsgs_N_1 предназначен только для симуляции. Можно сгенерировать код AUTOSAR C и файлы ARXML для моделей компонента отправителя и приемника, но не для содержащей модель уровня композиции.

Точно так же можно запустить симуляцию цикл (SIL) для моделей компонента отправителя и приемника, но не для модели уровня композиции.

Симулируйте управляемую событиями связь AUTOSAR с приемником отправителя в очереди

Этот пример показывает модель уровня композиции, в которой входное событие вызова функции Simulink активирует обработку компонента приемника сообщения в очереди. Пример реализован с использованием сообщений Stateflow. Для получения дополнительной информации о примерах обмена сообщениями Stateflow, смотрите Реализация AUTOSAR в очереди отправки и получения при помощи Stateflow Messaging.

Этот пример использует три модели в папке matlabroot/ help/toolbox/autosar/examples (cd в папку). Если вы копируете файлы в рабочую папку, соедините модели.

  • mAutosarDREventMsgs.slx (верхняя часть)

  • mAutosarMsgSender.slx

  • mAutosarHMILogicEvent.slx

Модель уровня состава mAutosarDREEventMsgs включает в себя компонент отправителя и компонент приемника в качестве ссылочных моделей. Он соединяет порт сообщения отправителя DashLight к промежуточным Data Receive Trigger логика, которая, в свою очередь, соединяется с портом сообщения приемника MsgIn и порт триггера функции Trigger.

Этот рисунок показывает верхний уровень компонента отправителя в очереди AUTOSAR mAutosarMsgSender, который содержит диаграмму Stateflow Turn Signal Generator. График message-line выхода соединяется с исходным портом корня Simulink DashLight. (Этот компонент отправителя аналогичен компоненту mAutosarSenderSWC1 в примерах симуляции Stateflow 1-to-1 и N-to-1 в реализации AUTOSAR Queued Send и Receive при помощи Stateflow Messaging.)

Этот рисунок показывает логику, реализованную в Turn Signal Generator график. График имеет четыре состояния - ActivateLeft, DeactivateLeft, ActivateRight, и DeactivateRight. Каждое состояние содержит действия входа, которые присваивают значение данным сообщения и отправляют сообщение. (См. раздел «Связь с диаграммами Stateflow путем отправки сообщений» (Stateflow).) Периодическая синхронизация управляет выходом сообщения.

Этот рисунок показывает Data Receiver Trigger график, расположенный между компонентами отправителя и приемника.

Чтобы получить сообщение, логика приемника в очереди использует receive(M):

  • Если допустимое сообщение M существует, receive(M) возвращает true.

  • Если допустимое сообщение не существует, график удаляет сообщение из связанной очереди и receive(M) возвращает true. Если receive(M) удаляет сообщение из очереди, длина очереди падает на единицу.

  • Если сообщение M недопустимо, и другое сообщение не может быть удалено из очереди, receive(M) возвращает false.

Можно разместить receive на переходе (для примера, [receive(M)]. Или, в состоянии, используйте if условие (для примера, if(receive(M))). Для получения дополнительной информации смотрите Связь с диаграммами Stateflow путем отправки сообщений (Stateflow).

Этот рисунок показывает логику, реализованную в Data Receiver Trigger график. График получает сообщения в очереди от компонента отправителя. Для каждого полученного сообщения график копирует полученные данные сообщения в исходящее сообщение, отправляет данные и отправляет событие вызова функции. (См. раздел «Связь с диаграммами Stateflow путем отправки сообщений» (Stateflow).)

Этот рисунок показывает верхний уровень компонента приемника в очереди AUTOSAR mAutosarHMILogicEvent, который содержит подсистему вызова функций Simulink. Входные порты подсистемы являются триггером вызова функции и портом приемника сообщений DashLight, который сконфигурирован для режима доступа к данным AUTOSAR QueuedExplicitReceive.

Эта подсистема вызова функций содержит диаграмму Stateflow ProcessHMIRequests и блок Trigger Port. Вход линии сообщения на графике соединяется с корневым входным портом Simulink Msg. Область возможностей сконфигурирована для отображения значения InvalidPath переменная.

Блок Trigger Port сконфигурирован для триггера вызова функции и инициированного шага расчета. Входные события вызова функции, отправленные из Data Receiver Trigger график в верхней модели активирует график.

Этот рисунок показывает логику, реализованную в ProcessHMIRequests график. ProcessHMIRequests содержит состояния HMIRequestProcessing, LeftTurnSignal, и RightTurnSignal. (Этот график приемника аналогичен диаграмме HMILogic в примерах симуляции 1 к 1 и N-to-1.)

  • HMIRequestProcessing получает сообщение из очереди сообщений, вызывает функцию для обработки сообщения и затем отбрасывает сообщение. The processRequest функция проверяет полученные данные сообщения на значения, потенциально установленные отправителем сообщения -- LeftTurnOn, RightTurnOn, LeftTurnOff, или RightTurnOff. На основе полученного значения функция увеличивает или уменьшает переменную счетчика запросов, либо leftTurnReqs или rightTurnReqs. Входные события вызова функции управляют входом сообщения. Если график неправильно активирован, InvalidPath для переменной задано значение 1.

  • LeftTurnSignal и RightTurnSignal каждый содержит состояния Off и On. Они переходят от Off на On на основе значения счетчика запросов leftTurnReqs или rightTurnReqs. Когда счетчик запросов больше нуля, графики задают переменную, либо leftSignalOut или rightSignalOut, к 1. Затем они переходят назад к Off состояние и задание leftSignalOut или rightSignalOut в 0.

Модель верхнего уровня mAutosarDREventMsgs предназначен только для симуляции. Можно сгенерировать код AUTOSAR C и файлы ARXML для моделей компонента отправителя и приемника, но не для содержащей модель уровня композиции.

Точно так же можно запустить симуляцию цикл (SIL) для моделей компонента отправителя и приемника, но не для модели уровня композиции.

Реализация отправки и получения в очереди AUTOSAR при помощи Stateflow Messaging

Реализация передачи и приема сообщений в очереди AUTOSAR при помощи сообщений Stateflow

Чтобы реализовать поведение компонента отправителя или приемника в очереди AUTOSAR, в этом примере используются сообщения Stateflow. Чтобы создать диаграмму Stateflow, выполните общую процедуру, описанную в Model an Assembly Line Feeder (Stateflow).

  1. Добавьте график к модели компонента отправителя или приемника в очереди AUTOSAR. Назовите график.

  2. Откройте график и добавьте состояния, связанные с сообщениями.

  3. Для каждого состояния добавьте действия входа. Поддерживаемые ключевые слова сообщения включают:

    • send(M) - Отправить сообщение М.

    • receive(M) - Получить сообщение М.

    • isvalid(M) - Проверьте, является ли сообщение M допустимым (всплывающее окно и не сбрасывается).

    • discard(M) - Явное сброс сообщения M. Сообщения неявно отбрасываются при выходе из состояния после завершения операции получения сообщения.

  4. Добавьте переходные линии и задайте условия или события перехода на этих линиях.

    • Используйте условия, когда вы хотите перейти на основе условного оператора или изменения входа значения из блока Simulink. Для получения дополнительной информации смотрите Переходы (Stateflow).

    • Используйте события, когда вы хотите перейти на основе инициируемого Simulink или вызова функции входного события. Для получения дополнительной информации смотрите Синхронизация компонентов модели посредством широковещательных событий (Stateflow).

  5. Задайте данные, которые хранят переменные состояния.

  6. Соедините входы и выводы линии сообщений на графике с корневыми входами и выходами Simulink.

Для получения дополнительной информации смотрите Сообщения (Stateflow).

В контексте диаграммы Stateflow можно изменить свойства сообщения, такие как тип данных и емкость очереди. (Список свойств см. в разделе «Установка свойств сообщения» (Stateflow).) Вы можете получить доступ к свойствам сообщения в Property Inspector, диалоговом окне Message Properties или в Model Explorer. Чтобы просмотреть или изменить свойства сообщения с помощью Property Inspector:

  1. Откройте график, которая использует сообщения.

  2. На вкладке Modeling откройте Symbols Pane и Property Inspector.

  3. В представлении «Символы» выберите сообщение. Property Inspector отображает панели для Message Data Properties и Advanced свойств.

    Если график находится в компоненте приемника, Property Inspector также отображает Message Queue Properties. Чтобы сконфигурировать компонент приемника для использования внешних очередей сообщений AUTOSAR RTE, убедитесь, что Use internal queue свойств очищена.

По умолчанию тип данных сообщения и значения емкости очереди наследуются от сообщения Stateflow, к которому присоединен корневой порт Simulink. Данные сообщения могут использовать следующие типы данных параметра Simulink: int типы, uint типы, типы с плавающей точкой, boolean, Enum, или Bus (struct).

Если вы используете импортированные типы данных шины или перечисления в диаграммах Stateflow, для симуляции требуются typedef. Чтобы автоматически сгенерировать typedef, выберите Generate typedefs for imported bus and enumeration types опции строения Simulink. В противном случае используйте параметр конфигурации Simulink Simulation Target > Custom Code > Header file, чтобы включить файлы заголовков с определениями.

Для примера реализации компонентов отправителя и приемника в очереди в строение 1 к 1, смотрите пример моделей компонента, используемого в Конфигурировании компонентов отправителя AUTOSAR и Приемника для связи в очереди и Симуляции конфигурации связи получателя отправителя в очереди AUTOSAR. Модели mAutosarSenderSWC1.slx и mAutosarReceiverSWC.slx расположены в папке matlabroot/ help/toolbox/autosar/examples (cd в папку).

Этот рисунок показывает верхний уровень компонента отправителя в очереди AUTOSAR mAutosarSenderSWC1, который содержит диаграмму Stateflow Turn Signal Generator. График message-line выхода соединяется с исходным портом корня Simulink MsgOut.

Этот рисунок показывает логику, реализованную в Turn Signal Generator график. График имеет четыре состояния - ActivateLeft, DeactivateLeft, ActivateRight, и DeactivateRight. Каждое состояние содержит действия входа, которые присваивают значение данным сообщения и отправляют сообщение. (См. раздел «Связь с диаграммами Stateflow путем отправки сообщений» (Stateflow).) Периодическая синхронизация управляет выходом сообщения.

Этот рисунок показывает верхний уровень компонента приемника в очереди AUTOSAR mAutosarReceiverSWC, который содержит диаграмму Stateflow HMILogic. Вход линии сообщения на графике соединяется с корневым входным портом Simulink MsgIn.

Чтобы получить сообщение, логика приемника в очереди использует receive(M):

  • Если допустимое сообщение M существует, receive(M) возвращает true.

  • Если допустимое сообщение не существует, график удаляет сообщение из связанной очереди и receive(M) возвращает true. Если receive(M) удаляет сообщение из очереди, длина очереди падает на единицу.

  • Если сообщение M недопустимо, и другое сообщение не может быть удалено из очереди, receive(M) возвращает false.

Можно разместить receive на переходе (для примера, [receive(M)]. Или, в состоянии, используйте if условие (для примера, if(receive(M))). Для получения дополнительной информации смотрите Связь с диаграммами Stateflow путем отправки сообщений (Stateflow).

Этот рисунок показывает логику, реализованную в HMILogic график. HMILogic содержит состояния HMIRequestProcessing, LeftTurnSignal, и RightTurnSignal.

  • HMIRequestProcessing получает сообщение из очереди сообщений, вызывает функцию для обработки сообщения и затем отбрасывает сообщение. The processRequest функция проверяет полученные данные сообщения на значения, потенциально установленные отправителем сообщения -- LeftTurnOn, RightTurnOn, LeftTurnOff, или RightTurnOff. На основе полученного значения функция увеличивает или уменьшает переменную счетчика запросов, либо leftTurnReqs или rightTurnReqs. Периодическая синхронизация управляет входом сообщения.

  • LeftTurnSignal и RightTurnSignal каждый содержит состояния Off и On. Они переходят от Off на On на основе значения счетчика запросов leftTurnReqs или rightTurnReqs и временной интервал. Когда счетчик запросов больше нуля, графики задают переменную, либо leftSignalOut или rightSignalOut, к 1. Через временной интервал они переходят назад к Off состояние и задание leftSignalOut или rightSignalOut в 0.

Для примеров реализации поставленных в очередь компонентов отправителя и приемника в N-to-1 строения, смотрите примеры моделей, используемых в Simulate N-to-1 AUTOSAR Queued Sender-Receiver Communication.

Для примера реализации управляемых событиями сообщений в очереди, смотрите примеры моделей, используемых в Simulate Event-Driven AUTOSAR Queued Sender-Receiver Communication.

Сконфигурируйте симуляцию связи отправитель-получатель в очереди AUTOSAR

Чтобы симулировать коммуникацию отправитель-получатель в очереди AUTOSAR в Simulink, создайте содержащую композицию, систему или модель тестовой обвязки. Включите компоненты отправителя и приемника в очередь в качестве ссылочных моделей.

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

  • Если вы симулируете N-to-1 или событийно-управляемые сообщения, вы обеспечиваете дополнительную логику между моделями компонента отправителя и приемника. Для получения примера смотрите Simulate N-to-1 AUTOSAR Queued Sender-Receiver Communication и Simulate Event-Driven AUTOSAR Queured Sender-Receiver Communication.

Этот пример показывает модель уровня композиции, которая содержит поставленный в очередь отправитель и приемник моделей компонента и реализует коммуникацию 1 к 1. Периодическое таймирование управляет обменом сообщениями. В примере используются три модели в папке matlabroot/ help/toolbox/autosar/examples (cd в папку). Если вы копируете файлы в рабочую папку, соедините модели.

  • mAutosarQueuedMsgs_1_1.slx (верхняя часть)

  • mAutosarSenderSWC1.slx

  • mAutosarReceiverSWC.slx

Модели mAutosarSenderSWC1 и mAutosarReceiverSWC являются одинаковыми компонентами отправителя и приемника, сконфигурированными в Конфигурирование компонентов отправителя и приемника AUTOSAR для обмена сообщениями в очереди и реализованными в Реализации передачи и приема сообщений в очереди AUTOSAR. Модель уровня состава mAutosarQueuedMsgs_1_1 включает их в качестве ссылочных моделей и соединяет порт компонента отправителя MsgOut к порту компонента приемника MsgIn.

Модель верхнего уровня mAutosarQueuedMsgs_1_1 предназначен только для симуляции. Можно сгенерировать код AUTOSAR C и файлы ARXML для моделей компонента отправителя и приемника, но не для содержащей модель уровня композиции.

Точно так же можно запустить симуляцию цикл (SIL) для моделей компонента отправителя и приемника, но не для модели уровня композиции.

Симулируйте N-to-1 AUTOSAR в очереди связи между отправителем и получателем

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

Этот пример использует четыре модели в папке matlabroot/ help/toolbox/autosar/examples (cd в папку). Если вы копируете файлы в рабочую папку, соедините модели.

  • mAutosarQueuedMsgs_N_1.slx (верхняя часть)

  • mAutosarSenderSWC1.slx

  • mAutosarSenderSWC2.slx

  • mAutosarReceiverSWC.slx

Модель уровня состава mAutosarQueuedMsgs_N_1 включает в себя два компонента отправителя и компонент приемника в качестве ссылочных моделей. Он соединяет компонент отправителя MsgOut порты к промежуточным MsgJoin логика обработки, которая, в свою очередь, соединяется с компонентом приемника MsgIn порт.

Модели mAutosarSenderSWC1 и mAutosarReceiverSWC являются одинаковыми компонентами отправителя и приемника, сконфигурированными в Конфигурирование компонентов отправителя и приемника AUTOSAR для обмена сообщениями в очереди и реализованными в Реализации передачи и приема сообщений в очереди AUTOSAR. Второй компонент отправителя, mAutosarSenderSWC2, подобен mAutosarSenderSWC1, но реализует второй тип входа сообщения для обработки приемником.

Этот рисунок показывает верхний уровень компонента отправителя в очереди AUTOSAR mAutosarSenderSWC2, который содержит диаграмму Stateflow Hazard Signal Generator. График message-line выхода соединяется с исходным портом корня Simulink MsgOut.

Этот рисунок показывает логику, реализованную в Hazard Signal Generator график. График имеет два состояния - HazardOff и HazardOn. Каждое состояние содержит действия входа, которые присваивают значения данным сообщения и отправляют сообщения. (См. раздел «Связь с диаграммами Stateflow путем отправки сообщений» (Stateflow).) Периодическая синхронизация управляет выходом сообщения.

Этот рисунок показывает MsgJoin график, расположенный между компонентами отправителя и приемника.

Этот рисунок показывает логику, реализованную в MsgJoin график. График получает сообщения в очереди от обоих компонентов отправителя и выводит их, по одному, в компонент приемника. Сообщения от первого компонента отправителя, mAutosarSenderSWC1.slx, обрабатываются первыми. Для каждого полученного сообщения график копирует полученные данные сообщения в исходящее сообщение, отправляет данные и отбрасывает полученное сообщение. (См. раздел «Связь с диаграммами Stateflow путем отправки сообщений» (Stateflow).)

Модель верхнего уровня mAutosarQueuedMsgs_N_1 предназначен только для симуляции. Можно сгенерировать код AUTOSAR C и файлы ARXML для моделей компонента отправителя и приемника, но не для содержащей модель уровня композиции.

Точно так же можно запустить симуляцию цикл (SIL) для моделей компонента отправителя и приемника, но не для модели уровня композиции.

Определите, когда очередь переполнена

Чтобы проверить, утеряно ли сообщение, поскольку оно было отправлено в очередь, которая уже была заполнена, используйте Stateflow overflowed оператор:

overflowed(message_name)
Как использовать overflowed оператор, установите модель в autosar.tlc цель для симуляции и генерации кода и проверьте, что сообщение inport или outport соединяется с внешней очередью. На каждом временном шаге значение этого оператора устанавливается, когда график добавляет сообщение в очередь или удаляет сообщение из нее. Недопустимое использование overflowed оператор перед отправкой или извлечением сообщения в тот же временной шаг или для проверки состояния переполнения локальной очереди сообщений.

По умолчанию, когда очередь сообщений переполнена, симуляция останавливается с ошибкой. Чтобы предотвратить ошибку времени выполнения и разрешить overflowed оператор для динамической реакции на сброшенные сообщения, установите значение свойства Queue Overflow Diagnostic равным Warning или None. Для получения дополнительной информации см. Раздел «Диагностика переполнения очереди» (Stateflow).

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

  • Защитите переход с сообщением и overflowed оператор.

  • Защитите переход с сообщением и вызовите overflowed оператор в действии входа целевого состояния.

  • Охрана состояния on действие с сообщением и вызов overflowed оператор в действии.

  • В состояние активности используйте receive оператор, за которым следует overflowed оператор.

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

Проверьте переполнение выходного сообщения.  Чтобы проверить состояние переполнения очереди выходных сообщений, сначала добавьте сообщение в очередь. Вы можете:

  • Используйте send оператор, за которым следует overflowed оператор.

  • Используйте forward оператор, за которым следует overflowed оператор.

Вызов overflowed оператор перед отправкой или пересылкой выхода сообщения в тот же временной шаг результатов в ошибку времени выполнения.

См. также

Похожие примеры

Подробнее о