Basic system structure and best practices Basic

The goal of this document is to enable a new PROTOS miniHIL user to understand the basic system structure and best practices.

Basic system structure

Test actor

A typical miniHIL system contains a single test actor on the top level. This test actor controls the test execution and orchestrates the behavior of the whole system. It is usually not recommended to create multiple test actors.

The interface of the test actor is defined in a PortProvider "actor class". This actor class should be defined as abstract in a separate .room file. Commonly all cage files in a single project use the same actor class as interface.

Usually a "main" cage file should be used which contains the TestActor definition. This main file should not contain any other cage elements (e.g. no Sequence, Step, TestSuite). Instead _TestSuite_s should be defined in separate cage files and should be imported into the main file.

Here is an example for the main file of a test actor:

TestModel test.Main

// Import of the port provider
import test.TestActorPortProvider.TestActorPortProvider

// Import of the other test suites
import test.MotorControlUart.*
import test.Temperature.*

interface:
	ActorClass TestActorPortProvider
;

targetcode:
	``
	``
;

/**
* This is the only test actor defined in the system
*/
TestActor MainTestActor:
	MotorControlUartBringUp
	TemperatureTests

    // More test suites should be added here and imported above
;

Application structure

The "root" of every miniHIL test project is the Application actor which should be defined in the MiniHilProject.room file. This actor commonly contains the (one and only) test actor (of the system), the simulation elements and any other actors which are used in conjunction with the test cases. Usually this actor also contains all or most of the Actors which provide the hardware abstraction (e.g. UART, DigitalIN/OUT, AnalogIn/OUT, etc.). That way it is relatively easy to understand the connection of the test actor ports to the actual IOs.

We suggest to organize the structure in the following way:

  • The test actor at the top of the screen taking most of the horizontal space

  • Support actors which do not access the hardware (e.g. time measurement) on the right side of the screen

  • Actors accessing the hardware (e.g. UART, DigitalIn/Out, AnalogIn/Out) on the bottom of the screen

  • Actors which which do data processing between the hardware and the test actor are placed in between the test actor and the hardware actors.

Application Structure

Project folder structure

We suggest to split the files of your project into separate folders for test and simulation and project specific HAL elements.

MiniHILProject
|-- src-user
|   |-- [user specific c sources and headers which should be included in the build]
|-- model-user
|   |-- actors
|       |-- MotorSim.room
|       |-- TemperatureSim.room
|       |-- [......].room
|   |-- test
|       |-- Main.cage
|       |-- Startup.cage
|       |-- Functionality1.cage
|       |-- ....
|       |-- TestActorPortProvider.room
|-- MiniHilProject.room

For projects with multiple, closely related product variants that share the same IO mapping and most of the tested functions, you can organize your setup around a common test library and per-variant projects. This is described in more detail in the following How-To:

Managing Product Variants with the miniHIL