 Report Overview
 Report Overview
The report follows the same structure as the editor. Select elements in ten menu on the left to navigate.
 Report Overview
 Report Overview
The report follows the same structure as the editor. Select elements in ten menu on the left to navigate.
| μRTE | |
|---|---|
|  uRTE version | 2024.12.06 | 
| Model | |
|  The name of the file containing the model. | uRTEDemo_03_Nucleo-F446RE_SystemStates_10_Model | 
|  Description of the model as defined in the top node of the model. | System States Project - Embedded System Development with µRTEThis 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: 
 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_1 | 
|  Date and time when this report was generated. | 13.03.2025 14:32:07 | 
|  The hash of the file containing the model. | 53j3LckasHnYib4YRJ0mQjXom8Z1dkZsDhW4k5mXP/lswmkgT31NAKE3bvod7bEH5+/qVqNjaq9sfn9SCRcuAA== | 
| SIL configuration | |
|  Alias for the Safety Integrity Level (SIL) | SIL | 
|  User alias for abstract SIL QM | QM | 
|  User alias for abstract SIL_1 | SIL_1 | 
|  User alias for abstract SIL_2 | SIL_2 | 
|  User alias for abstract SIL_3 | SIL_3 | 
|  User alias for abstract SIL_4 | SIL_4 | 
|  User alias for abstract SIL_5 | SIL_5 | 
| RTE configuration | |
|  Base path for RTE code generation. | A:\GIT\BD\uRTE\development\20_TestAndDemo\STM\Nucelo-F446RE\uRTEDemo_03_Nucleo-F446RE_SystemStates\20_Code\ | 
|  Folder for activation engine and state handler. | src_rte\activation\ | 
|  Folder for the backboard (file creating global signal objects). | src_rte\signals\bb\ | 
|  Folder for configuration files. | src_rte\config\ | 
|  Folder for driver type definitions. | src_rte\driver_types\ | 
|  Folder for linker description files. | \ | 
|  Folder for signal class files. | src_rte\signals\ | 
|  Folder for the signal class configuration. | src_rte\signals\cfg\ | 
|  Default folder for software components (application code files). | src_asw\swc\ | 
|  Folder for type definitions. | src_rte\signals\types\ | 
|  Programming language in which the code shall be generated. | CPP | 
|  Within runnables the signal payload typically is copied from the signal to a local buffer. The buffers can be generated automatically. | snippets | 
|  Defines the behavior of the signals "get" method in case an invalid signal is read. | update_invalid | 
|  Defines if a data-signal is valid (and operations such as "get" return success) if it is in the initialized state. | false | 
|  Defines if signals have an ISR API by default or if it is configurable individualy per signal. | none | 
| Report configuration | |
|  Base path for Report generation. | 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. | false | 
|  If set to true, all diagrams will be regenerated. If set to false, they will only be generated if the content changed. | false | 
 Safety Warnings (35)
 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)
 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)
 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)
 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)
 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. |