uRTEDemo_03_Nucleo-F446RE_SystemStates_10_Model

Report Overview

The report follows the same structure as the editor. Select elements in ten menu on the left to navigate.

Properties

μRTE
uRTE version
Version
2024.12.06
Model
The name of the file containing the model.
Model name
uRTEDemo_03_Nucleo-F446RE_SystemStates_10_Model
Description of the model as defined in the top node of the model.
Model description

System States Project - Embedded System Development with µRTE

This project demonstrates the application of Model-Based Systems Engineering (MBSE) principles to develop a complex embedded system, focusing on the management of operational states. It is the culmination of a series of projects designed to illustrate the progressive use of µRTE, starting from a basic template and building towards a fully functional system.

Hardware Platform: STM Nucleo F446RE

Project Overview:

This project builds upon the foundational knowledge established in the "Template" and "Making an LED Blink" projects. While those projects introduced basic configurations, data flows, and driver implementations, the "System States" project delves into advanced features and the crucial aspect of managing operational states. This project models a system that transitions through various operational states, demonstrating how µRTE can be used to define, manage, and verify complex state-based behaviour.

Key Features Demonstrated:

  • Advanced State Management: Modeling of complex operational states and transitions.
  • Detailed System Behavior: Capturing intricate interactions and dependencies within the system.
  • Comprehensive Model-Driven Development: Utilizing the model to generate executable software architecture.
  • Traceability: Ensuring clear links between requirements, design, and implementation.

Learning Resources:

To provide a comprehensive learning experience, this project is accompanied by a series of YouTube videos. These videos offer step-by-step demonstrations of the modeling process, showcasing how the tool is used to create and manage the system states project.

These videos provide practical insights into the tool's capabilities and how it can be used to develop robust embedded systems.

Getting Started:

This project serves as an example of how a system can be modelled. Users can explore the project files and associated videos to gain a deeper understanding of MBSE principles and the capabilities of µRTE.

Highest SIL mapped to an safety implementation unit.
SIL
SIL_1
Date and time when this report was generated.
Generated
13.03.2025 14:32:07
The hash of the file containing the model.
Model hash
53j3LckasHnYib4YRJ0mQjXom8Z1dkZsDhW4k5mXP/lswmkgT31NAKE3bvod7bEH5+/qVqNjaq9sfn9SCRcuAA==
SIL configuration
Alias for the Safety Integrity Level (SIL)
SIL alias
SIL
User alias for abstract SIL QM
QM
QM
User alias for abstract SIL_1
SIL_1
SIL_1
User alias for abstract SIL_2
SIL_2
SIL_2
User alias for abstract SIL_3
SIL_3
SIL_3
User alias for abstract SIL_4
SIL_4
SIL_4
User alias for abstract SIL_5
SIL_5
SIL_5
RTE configuration
Base path for RTE code generation.
RTE base
A:\GIT\BD\uRTE\development\20_TestAndDemo\STM\Nucelo-F446RE\uRTEDemo_03_Nucleo-F446RE_SystemStates\20_Code\
Folder for activation engine and state handler.
Folder activation
src_rte\activation\
Folder for the backboard (file creating global signal objects).
Folder blackboard
src_rte\signals\bb\
Folder for configuration files.
Folder config
src_rte\config\
Folder for driver type definitions.
Folder driver types
src_rte\driver_types\
Folder for linker description files.
Folder linker
\
Folder for signal class files.
RTE base
src_rte\signals\
Folder for the signal class configuration.
Folder signals
src_rte\signals\cfg\
Default folder for software components (application code files).
Folder SWCs
src_asw\swc\
Folder for type definitions.
Folder types
src_rte\signals\types\
Programming language in which the code shall be generated.
Code language
CPP
Within runnables the signal payload typically is copied from the signal to a local buffer. The buffers can be generated automatically.
Local signal buffer
snippets
Defines the behavior of the signals "get" method in case an invalid signal is read.
Read invalid signal behavior
update_invalid
Defines if a data-signal is valid (and operations such as "get" return success) if it is in the initialized state.
Signal validity for initialized signal
false
Defines if signals have an ISR API by default or if it is configurable individualy per signal.
Generate Signal ISR API
none
Report configuration
Base path for Report generation.
Report base
A:\GIT\BD\uRTE\development\20_TestAndDemo\STM\Nucelo-F446RE\uRTEDemo_03_Nucleo-F446RE_SystemStates\30_Report\
If set to true, HTML resources will be embedded into the file. If set to false, resources will be generated into the output folder and referenced.
Embed HTML resources
false
If set to true, all diagrams will be regenerated. If set to false, they will only be generated if the content changed.
Regenerate Diagrams
false

All warnings

Safety Warnings (35)

All Safety Warnings of this model.
Safety warnings are related to the Requirements Layer, especially the SIL.

Blinking LED has a SIL required of SIL_1 but a SIL achieved of QM. This is caused by the following referenced implementation units: PA5 (QM), ButtonRead (QM), drv_LED (QM), run_LED (QM), run_readButton (QM)
Button Timebase has a SIL required of SIL_1 but a SIL achieved of QM
ButtonRead has a SIL required of SIL_1 but a SIL achieved of QM
LED timebase has a SIL required of SIL_1 but a SIL achieved of QM
PA5 has a SIL required of SIL_1 but a SIL achieved of QM
UART has a SIL required of SIL_1 but a SIL achieved of QM. This is caused by the following referenced implementation units: USART (QM), ButtonRead (QM), UART out (QM), run_UART_send (QM), run_UART_wakeUp (QM), run_readButton (QM)
UART out has a SIL required of SIL_1 but a SIL achieved of QM
USART has a SIL required of SIL_1 but a SIL achieved of QM
button state has a SIL required of SIL_1 but a SIL achieved of QM
drv_LED has a SIL required of SIL_1 but a SIL achieved of QM
press_cnt has a SIL required of SIL_1 but a SIL achieved of QM
run_LED has a SIL required of SIL_1 but a SIL achieved of QM
run_UART_send has a SIL required of SIL_1 but a SIL achieved of QM
run_UART_wakeUp has a SIL required of SIL_1 but a SIL achieved of QM
run_readButton has a SIL required of SIL_1 but a SIL achieved of QM
Multiple Technical functions for Task Button: Blinking LED, UART
Multiple Technical functions for ButtonRead: Blinking LED, UART
Multiple Technical functions for run_readButton: Blinking LED, UART
Mixed SILs in Button : QM, SIL_1.
Mixed SILs in UART : QM, SIL_1.
Mixed SILs in .button : QM, SIL_1.
.button needs a SIL of SIL_1 but is using main for storage which has a achieved SIL of QM.
.rtos.task.Button needs a SIL of SIL_1 but is using main for storage which has a achieved SIL of QM.
.rtos.task.LED needs a SIL of SIL_1 but is using main for storage which has a achieved SIL of QM.
.rtos.task.UART needs a SIL of SIL_1 but is using main for storage which has a achieved SIL of QM.
.rtos.task.uRTE needs a SIL of SIL_1 but is using main for storage which has a achieved SIL of QM.
.uRTE needs a SIL of SIL_1 but is using main for storage which has a achieved SIL of QM.
Memory referenced by main for the stack of Button is using main with a SIL achieved of QM, which does not satisfy the SIL required of SIL_1 for this task.
Memory referenced by main for the stack of LED is using main with a SIL achieved of QM, which does not satisfy the SIL required of SIL_1 for this task.
Memory referenced by main for the stack of UART is using main with a SIL achieved of QM, which does not satisfy the SIL required of SIL_1 for this task.
Memory referenced by main for the stack of ActivationEngine is using main with a SIL achieved of QM, which does not satisfy the SIL required of SIL_1 for the central activation engine.
Button needs a SIL of SIL_1 but is executing on Arm® Cortex®-M4 which has a achieved SIL of QM.
LED needs a SIL of SIL_1 but is executing on Arm® Cortex®-M4 which has a achieved SIL of QM.
UART needs a SIL of SIL_1 but is executing on Arm® Cortex®-M4 which has a achieved SIL of QM.
Arm® Cortex®-M4 (QM) was selected for execution for ActivationEngine which does not satisfy the SIL required of SIL_1.

Design Warnings (1)

All Design Warnings of this model.
Design warnings are related the configuration of elements within the model.

BaseProtection has no content and therefore no effect on the system behaviour.

RTE Warnings (2)

All RTE Warnings of this model.
RTE warnings are related to the configured behaviour of the RTE.

HWO_UART allows pointer access to its payload.
.button is accessible from multiple tasks: Button, UART.

Testing Warnings (13)

All Testing Warnings of this model.
Testing warnings are related to the tests in the testing layer and their depedencies.

(Test_128) Smoke-Test is not referenced by an requirement.
(SafetyRequirement_110) Hardware Interfacing is not referencing a test and not all refinements reference a test.
(SafetyRequirement_96) Inter-task communication is not referencing a test and not all refinements reference a test.
(Requirement_94) LED is not referencing a test but all refinements reference a test.
(SafetyRequirement_111) SignalLayer features is not referencing a test but all refinements reference a test.
(SafetyRequirement_115) Protection Sets is not referencing a test but all refinements reference a test.
(SafetyRequirement_93) Runnable activation by signal events is not referencing a test but all refinements reference a test.
(SafetyRequirement_94) Global variables is not referencing a test but all refinements reference a test.
(SafetyRequirement_95) Runnable activation by cyclic events is not referencing a test but all refinements reference a test.
(SafetyRequirement_97) local and global signals is not referencing a test but all refinements reference a test.
(SafetyRequirement_98) Multiple System-States is not referencing a test but all refinements reference a test.
(Test_128) Smoke-Test is not rejected or implemented.
(Test_134) UART functional/system test is not rejected or implemented.

Requirements Warnings (2)

All Requirements Warnings of this model.
Requirements warnings are related to the Requirements layer.

(SafetyRequirement_110) Hardware Interfacing is not rejected or implemented.
(SafetyRequirement_111) SignalLayer features is not rejected or implemented.