При обмене данными с получателем (S-R) в очереди AUTOSAR программные компоненты AUTOSAR считывают и записывают данные в другие компоненты или службы. Данные, отправленные программным компонентом отправителя AUTOSAR, добавляются в очередь, предоставляемую окружением выполнения AUTOSAR (RTE). Вновь полученные данные не перезаписывают существующие непрочитанные данные. Позже программный компонент приемника считывает данные из очереди.
Для реализации обмена данными S-R в очереди, программные компоненты AUTOSAR определяют:
Интерфейс отправителя-получателя AUTOSAR с элементами данных.
AUTOSAR обеспечивает и требует порты, которые отправляют и получают данные в очереди.
В Simulink®, можно:
Создайте интерфейсы и порты S-R в очереди AUTOSAR с помощью словаря AUTOSAR.
Модель AUTOSAR обеспечивает и требует порты с помощью выходов и входных портов корневого уровня Simulink.
Сопоставьте выходные порты и входные порты с AUTOSAR, обеспечивающими и требующими порты, с помощью редактора Отображения. Установите режимы доступа к данным AUTOSAR на QueuedExplicitSend
или QueuedExplicitReceive
.
Чтобы смоделировать отправку и прием данных AUTOSAR с помощью очереди, используйте блоки Simulink Send и Receive. Если ваша реализация связи S-R в очереди включает состояния или требует логики принятия решений, используйте Stateflow® чарты. Можно обрабатывать ошибки, возникающие, когда очередь пуста или полна. Можно задать размер очереди. Для получения дополнительной информации смотрите Обзор сообщений Simulink.
Можно симулировать коммуникацию отправитель-получатель (S-R) в очереди AUTOSAR между моделями компонента, например, в симуляции уровня композиции. Отправители и приемники данных могут запускаться с различными скоростями. Несколько отправителей данных могут взаимодействовать с одним приемником данных.
Чтобы начать, можно импортировать компоненты с поставленными в очередь интерфейсами S-R и портами из файлов ARXML в Simulink или использовать Simulink, чтобы создать интерфейсы и порты.
Рабочий процесс Simulink для моделирования отправки и получения в очереди AUTOSAR
Сконфигурируйте компоненты отправителя и приемника AUTOSAR для обмена данными в очереди
Сконфигурируйте симуляцию связи отправитель-получатель в очереди AUTOSAR
Симулируйте N-to-1 AUTOSAR в очереди связи между отправителем и получателем
Симулируйте управляемую событиями связь AUTOSAR с приемником отправителя в очереди
Реализация отправки и получения в очереди AUTOSAR при помощи Stateflow Messaging
Эта процедура описывает общий рабочий процесс моделирования компонентов отправителя и приемника в очереди Autosar в Simulink.
Сконфигурируйте одну или несколько моделей как компоненты отправителя в очереди AUTOSAR, и одну модель как компонент приемника в очереди AUTOSAR. Для каждой модели компонента используйте AUTOSAR Dictionary и редактор Code Mappings, чтобы:
Создайте интерфейс данных S-R и его элементы данных.
Создайте порт отправителя или приемника.
Сопоставьте порт отправителя или приемника с выходным портом Simulink для отправки или входным портом для получения. Установите режим доступа к данным AUTOSAR равным QueuedExplicitSend
или QueuedExplicitReceive
.
Для получения примера см. раздел «Настройка компонентов AUTOSAR и Приемника для обмена данными в очереди».
Чтобы реализовать поведение компонента отправителя или приемника в очереди AUTOSAR, используйте блоки Simulink Send и Receive. Для получения дополнительной информации смотрите Обзор сообщений Simulink.
Если ваша реализация связи S-R в очереди включает состояния или требует логики принятия решений, используйте диаграммы Stateflow.
Дополнительные сведения см. в разделе Реализация сообщений отправки и получения в очереди AUTOSAR.
Когда вы создаете модель компонента отправителя или приемника в очереди AUTOSAR:
Сгенерированный код C содержит вызовы AUTOSAR Rte_Send_<port>_<DataElement>
или Rte_Receive_<port>_<DataElement>
API.
Сгенерированный код обрабатывает состояние вызовов приема сообщений.
Обработка статуса отправки сообщений (например, переполнение очереди) может быть смоделирована только в Stateflow. Сгенерированный код обрабатывает статус отправки сообщения только, если компонент отправителя в очереди реализует логику Stateflow.
Экспортированные файлы ARXML содержат описание для обмена данными между отправителем и получателем в очереди. Сгенерированный ComSpec
для порта в очереди включает тип порта и длину очереди (на основе свойства сообщения Simulink QueueCapacity
). В SwDataDefProps
сгенерирован для элемента данных порта в очереди, SwImplPolicy
установлено в Queued
.
Чтобы симулировать коммуникацию отправитель-получатель в очереди AUTOSAR в Simulink, создайте содержащую композицию, систему или модель тестовой обвязки. Включите компоненты отправителя и приемника в очередь в качестве ссылочных моделей.
Чтобы обеспечить логику организации очереди между компонентами отправителя и приемника, можно вставить блок 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 в Simulink. В примере используются две модели в папке
(matlabroot
/ help/toolbox/autosar/examplescd
в папку). Если вы копируете файлы в рабочую папку, соедините модели. Чтобы увидеть эти модели, соединенные для симуляции, смотрите Настройте Симуляцию Связи Отправитель-Получатель в ОЧЕРЕДИ AUTOSAR.
mAutosarSlSenderSWC1.slx
mAutosarSlReceiverSWC.slx
Откройте модель AUTOSAR, которую вы хотите сконфигурировать как компонент отправителя или приемника в очереди. Чтобы создать интерфейс данных S-R и порт отправителя или приемника в очереди:
Откройте словарь AUTOSAR.
Выберите S-R Interfaces. Чтобы создать интерфейс данных S-R, нажмите кнопку Add. Укажите его имя и количество связанных элементов данных S-R. Этот пример использует один элемент данных как в компонентах отправителя, так и в компонентах приемника.
Выберите и разверните новый интерфейс S-R. Выберите DataElements и измените атрибуты элемента данных. Этот рисунок показывает элемент данных DE1
для компонента отправителя.
Разверните узел AtomicComponents и выберите компонент AUTOSAR. Разверните компонент.
Выберите SenderPorts или ReceiverPorts представление и используйте его, чтобы добавить требуемый порт отправителя или приемника. Для каждого порта S-R выберите созданный интерфейс S-R. Для компонента отправителя этот рисунок показывает порт отправителя MsgOut
, который использует интерфейс S-R Out1
.
Откройте редактор Отображения. Выберите вкладку 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, этот пример использует:
Блоки сообщений Simulink для реализации обмена сообщениями.
Диаграммы Stateflow для реализации логики принятия решений.
Этот пример объясняет конструкцию примерных моделей mAutosarSlSenderSWC1.slx
и mAutosarSlReceiverSWC.slx
. Эти модели расположены в папке
(matlabroot
/ help/toolbox/autosar/examplescd
в папку).
Другие примеры развертывают те же модели отправителя и приемника в строениях обмена сообщениями 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 в 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/examplescd
в папку). Если вы копируете файлы в рабочую папку, соедините модели.
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 коммуникацию. Периодическое таймирование управляет обменом сообщениями. Пример расширяет пример 1 на 1, добавляя две дополнительные модели отправителя и обеспечивая логику потока между отправителями и приемником.
Этот пример использует четыре модели в папке
(matlabroot
/ help/toolbox/autosar/examplescd
в папку). Если вы копируете файлы в рабочую папку, соедините модели.
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) для моделей компонента отправителя и приемника, но не для модели уровня композиции.
Этот пример показывает модель уровня композиции, в которой входное событие вызова функции Simulink активирует обработку компонента приемника сообщения в очереди. Пример реализован с использованием сообщений Stateflow. Для получения дополнительной информации о примерах обмена сообщениями Stateflow, смотрите Реализация AUTOSAR в очереди отправки и получения при помощи Stateflow Messaging.
Этот пример использует три модели в папке
(matlabroot
/ help/toolbox/autosar/examplescd
в папку). Если вы копируете файлы в рабочую папку, соедините модели.
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
Сконфигурируйте симуляцию связи отправитель-получатель в очереди AUTOSAR
Симулируйте N-to-1 AUTOSAR в очереди связи между отправителем и получателем
Чтобы реализовать поведение компонента отправителя или приемника в очереди AUTOSAR, в этом примере используются сообщения Stateflow. Чтобы создать диаграмму Stateflow, выполните общую процедуру, описанную в Model an Assembly Line Feeder (Stateflow).
Добавьте график к модели компонента отправителя или приемника в очереди AUTOSAR. Назовите график.
Откройте график и добавьте состояния, связанные с сообщениями.
Для каждого состояния добавьте действия входа. Поддерживаемые ключевые слова сообщения включают:
send(M)
- Отправить сообщение М.
receive(M)
- Получить сообщение М.
isvalid(M)
- Проверьте, является ли сообщение M допустимым (всплывающее окно и не сбрасывается).
discard(M)
- Явное сброс сообщения M. Сообщения неявно отбрасываются при выходе из состояния после завершения операции получения сообщения.
Добавьте переходные линии и задайте условия или события перехода на этих линиях.
Используйте условия, когда вы хотите перейти на основе условного оператора или изменения входа значения из блока Simulink. Для получения дополнительной информации смотрите Переходы (Stateflow).
Используйте события, когда вы хотите перейти на основе инициируемого Simulink или вызова функции входного события. Для получения дополнительной информации смотрите Синхронизация компонентов модели посредством широковещательных событий (Stateflow).
Задайте данные, которые хранят переменные состояния.
Соедините входы и выводы линии сообщений на графике с корневыми входами и выходами Simulink.
Для получения дополнительной информации смотрите Сообщения (Stateflow).
В контексте диаграммы Stateflow можно изменить свойства сообщения, такие как тип данных и емкость очереди. (Список свойств см. в разделе «Установка свойств сообщения» (Stateflow).) Вы можете получить доступ к свойствам сообщения в Property Inspector, диалоговом окне Message Properties или в Model Explorer. Чтобы просмотреть или изменить свойства сообщения с помощью Property Inspector:
Откройте график, которая использует сообщения.
На вкладке Modeling откройте Symbols Pane и Property Inspector.
В представлении «Символы» выберите сообщение. 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/examplescd
в папку).
Этот рисунок показывает верхний уровень компонента отправителя в очереди 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 в 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/examplescd
в папку). Если вы копируете файлы в рабочую папку, соедините модели.
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 коммуникацию. Периодическое таймирование управляет обменом сообщениями. Пример расширяет пример 1 на 1, добавляя вторую модель отправителя и обеспечивая логику потока между отправителями и приемником.
Этот пример использует четыре модели в папке
(matlabroot
/ help/toolbox/autosar/examplescd
в папку). Если вы копируете файлы в рабочую папку, соедините модели.
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
оператор перед отправкой или пересылкой выхода сообщения в тот же временной шаг результатов в ошибку времени выполнения.