| <!DOCTYPE html> |
| <html lang="en"> |
| <head> |
| <meta charset="utf-8"> |
| <meta http-equiv="X-UA-Compatible" content="IE=edge"> |
| <meta name="viewport" content="width=device-width, initial-scale=1"> |
| <!-- The above 3 meta tags *must* come first in the head; any other head content must come *after* these tags --> |
| <title>eTrice Documentation</title> |
| |
| <!-- Bootstrap --> |
| <link rel="stylesheet" type="text/css" href="css/bootstrap.min.css"/> |
| <link rel="stylesheet" type="text/css" href="css/metisMenu.min.css"/> |
| <link rel="stylesheet" type="text/css" href="css/font-awesome.min.css"/> |
| <link rel="stylesheet" type="text/css" href="css/prettify.css"/> |
| <link rel="stylesheet" type="text/css" href="css/custom.css"/> |
| <link rel="stylesheet" type="text/css" href="css/custom-common.css"/> |
| |
| <!-- HTML5 shim and Respond.js for IE8 support of HTML5 elements and media queries --> |
| <!-- WARNING: Respond.js doesn't work if you view the page via file:// --> |
| <!--[if lt IE 9]> |
| <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script> |
| <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script> |
| <![endif]--> |
| |
| </head> |
| <body> |
| |
| <!-- Fixed navbar --> |
| <nav class="navbar navbar-default navbar-static-top" role="navigation"> |
| <div class="container"> |
| <div class="navbar-header"> |
| <a class="navbar-brand" style="padding-bottom: 2px; padding-top: 4px;" href="introduction.html"><img style="height: 100%;" src="images/logo/etrice-logo-interim.png"></a> |
| </div> |
| <div id="navbar" class="collapse navbar-collapse"> |
| <ul class="nav navbar-nav"> |
| <li class="active"><a href="introduction.html">Online Documentation</a></li> |
| <li><a href="http://www.eclipse.org/forums/eclipse.etrice">Newsgroup</a></li> |
| <li><a href="https://www.eclipse.org/etrice/">eTrice Home</a></li> |
| <li><a href="https://www.eclipse.org/etrice/download.php">Downloads</a></li> |
| |
| <li><a href="https://git.eclipse.org/c/etrice/org.eclipse.etrice.git/">Git repository</a></li> |
| |
| </ul> |
| </div><!--/.nav-collapse --> |
| </div> |
| </nav> |
| |
| |
| |
| <div class="container"> |
| <div class="row"> |
| <div class="col-sm-3"> |
| <div id="sidebar" role="navigation"> |
| <ul class="nav metismenu" id="sidebarMenu"> |
| <li><a href="introduction.html" aria-expanded="false">Introduction <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="introduction.html#etrice-overview" aria-expanded="false">eTrice Overview <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="introduction.html#what-is-etrice-">What is eTrice?</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="introduction.html#reduction-of-complexity">Reduction of Complexity</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="introduction.html#introduction-room-language" aria-expanded="false">Introduction ROOM Language <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="introduction.html#scope-of-room">Scope of ROOM</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="introduction.html#basic-concepts">Basic Concepts</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="introduction.html#execution-models">Execution Models</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="tutorials.html" aria-expanded="false">Tutorials <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="tutorials.html#working-with-the-tutorials">Working with the tutorials</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="tutorials.html#getting-started-c">Getting Started C</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="tutorials.html#getting-started-c-">Getting Started C++</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="tutorials.html#getting-started-java">Getting Started Java</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="tutorials.html#tutorial-ping-pong-java-c-and-c-" aria-expanded="false">Tutorial Ping Pong Java, C and C++ <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="tutorials.html#scope">Scope</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="tutorials.html#create-the-structure">Create the structure</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="tutorials.html#implement-the-behavior">Implement the Behavior</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="tutorials.html#summary">Summary</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="tutorials.html#troubleshooting">Troubleshooting</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="standalone-generators.html">Standalone Generators</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html" aria-expanded="false">Examples <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="examples.html#the-c-examples-project" aria-expanded="false">The C examples project <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="examples.html#traffic-light-step-1">Traffic light - step 1</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html#traffic-light-step-2">Traffic light - step 2</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html#traffic-light-step-3">Traffic light - step 3</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html#traffic-light-step-4">Traffic light - step 4</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html#features">Features</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="examples.html#the-java-examples-project" aria-expanded="false">The Java examples project <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="examples.html#dynamic-actors-1">Dynamic Actors 1</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html#dynamic-actors-2">Dynamic Actors 2</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html#dynamic-actors-3">Dynamic Actors 3</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html#dynamic-actors-4">Dynamic Actors 4</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html#dynamic-actors-5">Dynamic Actors 5</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html#dynamic-actors-6">Dynamic Actors 6</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html#dynamic-actors-7">Dynamic Actors 7</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html#dynamic-actors-8">Dynamic Actors 8</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="examples.html#dynamic-actors-9">Dynamic Actors 9</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="room-concepts.html" aria-expanded="false">ROOM Concepts <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="room-concepts.html#actors">Actors</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="room-concepts.html#protocols">Protocols</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="room-concepts.html#ports">Ports</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="room-concepts.html#dataclass">DataClass</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="room-concepts.html#layering">Layering</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="room-concepts.html#finite-state-machines">Finite State Machines</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html" aria-expanded="false">eTrice Features <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="etrice-features.html#model-navigation" aria-expanded="false">Model Navigation <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="etrice-features.html#from-model-to-behavior-to-structure">From Model to Behavior to Structure</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#model-navigation">Model Navigation</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#navigating-behavior-diagrams">Navigating Behavior Diagrams</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#navigating-structure-diagrams">Navigating Structure Diagrams</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#etrice-java-projects" aria-expanded="false">eTrice Java Projects <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="etrice-features.html#eclipse-jdt-build">Eclipse JDT Build</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#automatic-diagram-layout-with-kieler" aria-expanded="false">Automatic Diagram Layout with KIELER <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="etrice-features.html#overview">Overview</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#performing-automatic-layout">Performing Automatic Layout</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#layout-options">Layout Options</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#configuring-layout-options">Configuring Layout Options</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#special-layout-options">Special Layout Options</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#further-references">Further References</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#annotations" aria-expanded="false">Annotations <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="etrice-features.html#annotation-type-definitions">Annotation Type Definitions</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#usage-and-effect-of-the-pre-defined-annotations">Usage and Effect of the Pre-defined Annotations</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#enumerations">Enumerations</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#etrice-models-and-their-relations" aria-expanded="false">eTrice Models and Their Relations <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="etrice-features.html#the-room-model">The ROOM Model</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#the-config-model">The Config Model</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#the-physical-model">The Physical Model</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#the-mapping-model">The Mapping Model</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#interface-contracts" aria-expanded="false">Interface Contracts <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="etrice-features.html#defining-contracts">Defining Contracts</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="etrice-features.html#contract-monitor-generation">Contract Monitor Generation</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html" aria-expanded="false">Feature Reference <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="feature-reference.html#roomlanguage" aria-expanded="false">ROOMLanguage <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="feature-reference.html#configmodel">ConfigModel</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#logicalmodel" aria-expanded="false">LogicalModel <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="feature-reference.html#actorclass">ActorClass</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#actorref">ActorRef</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#annotation">Annotation</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#annotationtype">AnnotationType</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#attribute">Attribute</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#binding">Binding</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#cpbranchtransition">CPBranchTransition</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#choicepoint">ChoicePoint</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#communicationtype">CommunicationType</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#continuationtransition">ContinuationTransition</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#dataclass">DataClass</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#datatype">DataType</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#entrypoint">EntryPoint</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#enumeration">Enumeration</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#executiontype">ExecutionType</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#exitpoint">ExitPoint</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#externalendport">ExternalEndPort</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#externaltype">ExternalType</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#inheritance">Inheritance</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#initialtransition">InitialTransition</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#internalendport">InternalEndPort</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#layerconnection">LayerConnection</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#logicalsystem">LogicalSystem</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#operation">Operation</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#port">Port</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#primitivetype">PrimitiveType</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#protocolclass">ProtocolClass</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#refinedstate">RefinedState</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#relayport">RelayPort</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#replication">Replication</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#sap">SAP</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#spp">SPP</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#serviceimplementation">ServiceImplementation</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#simplestate">SimpleState</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#state">State</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#stategraphnode">StateGraphNode</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#statemachine">StateMachine</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#subsystemclass">SubSystemClass</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#subsystemref">SubSystemRef</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#trpoint">TrPoint</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#transition">Transition</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#transitionpoint">TransitionPoint</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#triggeredtransition">TriggeredTransition</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#mappingmodel">MappingModel</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#physicalmodel">PhysicalModel</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#modeleditors" aria-expanded="false">ModelEditors <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="feature-reference.html#graphicalbehavioreditor">GraphicalBehaviorEditor</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#graphicalstructureeditor" aria-expanded="false">GraphicalStructureEditor <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="feature-reference.html#actorrefpropertydialog">ActorRefPropertyDialog</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#portpropertydialog">PortPropertyDialog</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#spppropertydialog">SPPPropertyDialog</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#structureeditorpalette">StructureEditorPalette</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#textualroomeditor" aria-expanded="false">TextualROOMEditor <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="feature-reference.html#outlineview">OutlineView</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#codegenerators" aria-expanded="false">CodeGenerators <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="feature-reference.html#ccodegenerator">CCodeGenerator</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#cppcodegenerator">CPPCodeGenerator</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#generationoptions">GenerationOptions</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#javacodegenerator">JavaCodeGenerator</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="feature-reference.html#msclogging">MSCLogging</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="Dave-Integration.html" aria-expanded="false">Dave Integration <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="Dave-Integration.html#dave-etrice-toolchain-tutorial" aria-expanded="false">DAVE-eTrice Toolchain Tutorial <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="Dave-Integration.html#introduction">Introduction</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="Dave-Integration.html#getting-started-without-operating-system">Getting Started without Operating System</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="Dave-Integration.html#getting-started-with-freertos">Getting Started with FreeRTOS</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="ResourceRequirements.html">Resource Requirements</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="developers-reference.html" aria-expanded="false">Developer's Reference <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="developers-reference.html#etrice-tool-developer-s-reference" aria-expanded="false">eTrice Tool Developer’s Reference <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="developers-reference.html#architecture" aria-expanded="false">Architecture <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="developers-reference.html#editor-and-generator-components">Editor and Generator Components</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="developers-reference.html#the-abstract-finite-state-machine-concept">The Abstract Finite State Machine Concept</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="developers-reference.html#runtimes">Runtimes</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="developers-reference.html#unit-tests">Unit Tests</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="developers-reference.html#component-overview" aria-expanded="false">Component Overview <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="developers-reference.html#room-language-overview">Room Language Overview</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="developers-reference.html#config-language-overview">Config Language Overview</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="developers-reference.html#aggregation-layer-overview">Aggregation Layer Overview</a></li> |
| |
| |
| |
| |
| |
| |
| <li><a href="developers-reference.html#generator-overview">Generator Overview</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| <li><a href="release-notes.html" aria-expanded="false">Release Notes <span class="fa arrow"></span></a> |
| <ul class="nav" aria-expanded="false"> |
| <li><a href="release-notes.html#2-0-0-migration">2.0.0 Migration</a></li> |
| |
| |
| |
| |
| |
| |
| </ul> |
| </li> |
| |
| |
| |
| |
| |
| </ul> |
| </div> |
| </div> |
| <span class="version pull-right">version 2.x</span></p> |
| <div class="col-sm-9"> |
| <h1><a href="#introduction" name="introduction"></a>Introduction</h1> |
| <h2><a href="#etrice-overview" name="etrice-overview"></a>eTrice Overview</h2> |
| <h3><a href="#what-is-etrice-" name="what-is-etrice-"></a>What is eTrice?</h3> |
| <p>eTrice provides an implementation of the ROOM modeling language (Real Time Object Oriented Modeling) together with editors, code generators for Java, C++ and C code and exemplary target middleware.</p> |
| <p>The model is defined in textual form (Xtext) with graphical editors (Graphiti) for the structural and behavioral (i.e. state machine) parts.</p> |
| <h3><a href="#reduction-of-complexity" name="reduction-of-complexity"></a>Reduction of Complexity</h3> |
| <p>eTrice is all about the reduction of complexity:</p> |
| <ul> |
| <li>structural complexity |
| <ul> |
| <li>by explicit modeling of hierarchical Actor containment, layering and inheritance</li> |
| </ul> |
| </li> |
| <li>behavioral complexity |
| <ul> |
| <li>by hierarchical state machines with inheritance</li> |
| </ul> |
| </li> |
| <li>team work complexity |
| <ul> |
| <li>because loosely coupled Actors provide a natural way to structure team work</li> |
| <li>since textual model notation allows simple branching and merging</li> |
| </ul> |
| </li> |
| <li>complexity of concurrent & distributed systems |
| <ul> |
| <li>because loosely coupled Actors are deployable to threads, processes, nodes</li> |
| </ul> |
| </li> |
| <li>complexity of variant handling and reuse (e.g. for product lines) |
| <ul> |
| <li>by composition of existing Actors to new structures</li> |
| <li>since Protocols and Ports make Actors replaceable</li> |
| <li>by inheritance for structure, behavior and Protocols</li> |
| <li>by making use of model level libraries</li> |
| </ul> |
| </li> |
| <li>complexity of debugging |
| <ul> |
| <li>model level debugging: state machine animation, data inspection and manipulation, message injection, generated message sequence charts</li> |
| <li>model checking easier for model than for code (detect errors before they occur)</li> |
| </ul> |
| </li> |
| </ul> |
| <h2><a href="#introduction-room-language" name="introduction-room-language"></a>Introduction ROOM Language</h2> |
| <h3><a href="#scope-of-room" name="scope-of-room"></a>Scope of ROOM</h3> |
| <p>This chapter will give a rough overview of what ROOM (<strong>R</strong>eal-time <strong>O</strong>bject-<strong>O</strong>riented <strong>M</strong>odeling) is and what it is good for. It will try to answer the following questions:</p> |
| <ul> |
| <li> |
| <p>Where does it come from?</p></li> |
| <li> |
| <p>Which kind of SW-Systems will be addressed?</p></li> |
| <li> |
| <p>What is the relation between object oriented programming and ROOM?</p></li> |
| <li> |
| <p>What are the benefits of ROOM?</p></li> |
| <li> |
| <p>Which consequences must be taken into account?</p></li> |
| </ul> |
| <h4><a href="#where-does-it-come-from-" name="where-does-it-come-from-"></a>Where does it come from?</h4> |
| <p>ROOM was developed in the 1990th on the background of the upcoming mobile applications with the goal to manage the complexity of such huge SW-Systems. From the very beginning ROOM has focused on a certain type of SW-Systems and is, in contrast to the UML, well suited for this kind of systems. In this sense, ROOM is a DSL (Domain Specific Language) for distributed, event driven, real time systems.</p> |
| <p>Bran Selic, Garth Gullekson and Paul T. Ward have published the concepts 1994 in the book <strong>Real-Time Object-Oriented Modeling</strong>. The company <em>ObjecTime</em>™ developed a ROOM tool which was taken over by <em>Rational SW</em>™ and later on by <em>IBM</em>™. The company <em>Protos Software GmbH</em>™ also developed a ROOM tool called <em>Trice</em>™ for control software for production machines and automotive systems. <em>Trice</em>™ is the predecessor of eTrice (see Introduction to eTrice).</p> |
| <p>From our point of view ROOM provides still the clearest, simplest, most complete and best suited modeling concepts for the real time domain. All later proposals like the UML do not fit as well to this kind of problems.</p> |
| <h4><a href="#which-kind-of-sw-systems-will-be-addressed-" name="which-kind-of-sw-systems-will-be-addressed-"></a>Which kind of SW Systems will be addressed?</h4> |
| <p>As mentioned before ROOM addresses distributed, event driven, real time systems. But what is a <em>real time system</em>? ROOM defines a set of properties which are typical for a real time system. These properties are:</p> |
| <ul> |
| <li> |
| <p>Timeliness</p></li> |
| <li> |
| <p>Dynamic internal structure</p></li> |
| <li> |
| <p>Reactiveness</p></li> |
| <li> |
| <p>Concurrency</p></li> |
| <li> |
| <p>Distribution</p></li> |
| <li> |
| <p>Reliability</p></li> |
| </ul> |
| <p>Each of these properties has potential to make SW development complex. If a given system can be characterized with a combination of or all of these properties, ROOM might be applied to such a system.</p> |
| <p>As an example take a look at a washing machine. The system has to react to user interactions, has to handle some error conditions like a closed water tap or a defective lye pump. It has to react simultaneously to all these inputs. It has to close the water valve within a certain time to avoid flooding the basement. So, the system can be characterized as timely, concurrent and reactive. As long as the washing machine does not transform to a laundry drier by itself, the system has no dynamic internal structure and as long as all functions are running on a single micro controller the (SW)-system is not distributed. ROOM fits perfect to such a system.</p> |
| <p>A SW system which mainly consists of data transformations like signal/image processing or a loop controller (e.g. a PID controller) cannot be characterized with any of the above mentioned properties. However, in the real world most of the SW systems will be a combination of both. ROOM can be combined with such systems, so that for example an actor provides a <em>run to completion</em> context for calculating an image processing algorithm or a PID controller.</p> |
| <h4><a href="#what-is-the-relation-between-oop-and-room-" name="what-is-the-relation-between-oop-and-room-"></a>What is the relation between OOP and ROOM?</h4> |
| <p>The relation between classical object oriented programming and ROOM is comparable to the relation between assembler programming and C programming. It provides a shift of the object paradigm. The classical object paradigm provides some kind of information hiding. Attributes can be accessed via access methods. Logical higher level methods provide the requested behavior to the user.</p> |
| <p>But as the figure illustrates, the classical object paradigm does not care about concurrency issues. The threads of control will be provided by the underlying operating system and the user is responsible to avoid access violations by using those operating system mechanisms directly (semaphore, mutex).</p> |
| <p><img src="images/010-RoomIntroduction02.png" alt="image"></p> |
| <p>ROOM provides the concept of a logical machine (called actor) with its own thread of control. It provides some kind of cooperative communication infrastructure with <em>run to completion</em> semantics. That makes developing of business logic easy and safe (see <a href="#basic-concepts">Basic Concepts</a>). The logical machine provides an encapsulation shell including concurrency issues (see <a href="#run-to-completion">Run to completion</a>).</p> |
| <p><img src="images/010-RoomIntroduction03.png" alt="image"></p> |
| <p>This concept of an object is much more general than the classic one.</p> |
| <h4><a href="#what-are-the-benefits-of-room-" name="what-are-the-benefits-of-room-"></a>What are the benefits of ROOM?</h4> |
| <p>ROOM has a lot of benefits and it depends on the user’s point of view which is the most important one. From a general point of view the most important benefit is, that ROOM allows to create SW systems very efficient, robust and safe due to the fact that it provides some abstract, high level modeling concepts combined with code generation and a small efficient runtime environment.</p> |
| <p>In detail:</p> |
| <ul> |
| <li> |
| <p>ROOM models contain well defined interfaces (protocols), which makes it easy to re-use components in different applications or e.g. in a test harness.</p></li> |
| <li> |
| <p>Graphical modeling makes it easy to understand, maintain and share code with other developers</p></li> |
| <li> |
| <p>Higher abstraction in combination with automated code generation provides very efficient mechanisms to the developer.</p></li> |
| <li> |
| <p>ROOM provides graphical model execution, which makes it easy to understand the application or find defects in a very early phase.</p></li> |
| </ul> |
| <h4><a href="#which-consequences-must-be-taken-into-account-" name="which-consequences-must-be-taken-into-account-"></a>Which consequences must be taken into account?</h4> |
| <p>Generating code from models will introduce some overhead in terms of memory footprint as well as performance. For most systems the overhead will be negligible. However, the decision for using ROOM should be made explicitly and it is always a trade off between development costs, time to market and costs in terms of a little bit more of memory and performance. Thanks to the powerful component model, ROOM is especially well suited for the development of software product lines with their need for reusable core assets.</p> |
| <p>Care must be taken during the introduction of the new methodology. Due to the fact that ROOM provides a shift of the object paradigm, developers and teams need a phase of adaption. Every benefit comes at a price.</p> |
| <h3><a href="#basic-concepts" name="basic-concepts"></a>Basic Concepts</h3> |
| <h4><a href="#actor-port-protocol" name="actor-port-protocol"></a>Actor, Port, Protocol</h4> |
| <p>The basic elements of ROOM are the actors with their ports and protocols. The protocol provides a formal interface description. The port is an interaction point where the actor interacts with its outside world. Each port has exactly one protocol attached. The sum of all ports builds up the complete interface of an actor. Each port can receive messages, with or without data, which are defined in the attached protocol. Each message will be handled by the actor’s behavior (state machine) or will be delegated to the actor’s internal structure.</p> |
| <table style="vertical-align: middle;text-align: center;" class="table"> |
| <tbody> |
| <tr> |
| <td><p><img src="images/040-ActorClass.png" alt="image"></p></td> |
| <td><pre><code class="room customHighlighted"><span class="keyword">ProtocolClass</span> ProtocolClass1 { |
| <span class="keyword">incoming</span> { |
| <span class="keyword">Message</span> m1(int32) |
| <span class="keyword">Message</span> m2() |
| } |
| <span class="keyword">outgoing</span> { |
| <span class="keyword">Message</span> m3(DataClass1) |
| <span class="keyword">Message</span> m4() |
| } |
| } |
| </code></pre></td> |
| </tr> |
| <tr> |
| <td><p><strong>Actor with sub actors</strong></p></td> |
| <td><p><strong>Protocol definition</strong> </p></td> |
| </tr> |
| </tbody> |
| </table> |
| <p>The actor provides access protection for its own attributes (including complex types, i.e. classical objects), including concurrency protection. An actor has neither public attributes nor public operations. The only interaction with the outside world takes place via interface ports. This ensures a high degree of re-usability on the actor level and provides an effective and safe programming model to the developer.</p> |
| <p>Receiving a message via a port will trigger the internal state machine. A transition will be executed depending on the message and the current state. Within this transition, detail level code will be executed and response messages can be sent.</p> |
| <p>With this model, a complex behavior can be divided into many relatively simple, linked actors. To put it the other way round: The complex behavior will be provided by a network of relatively simple components which are communicating with each other via well defined interfaces.</p> |
| <h4><a href="#hierarchy-in-structure-and-behavior" name="hierarchy-in-structure-and-behavior"></a>Hierarchy in Structure and Behavior</h4> |
| <p>ROOM provides two types of hierarchy. Behavioral hierarchy and structural hierarchy. Structural hierarchy means that actors can be nested to arbitrary depth. Usually you will add more and more details to your application with each nesting level. That means you can focus yourself on any level of abstraction with always the same element, the actor. Structural hierarchy provides a powerful mechanism to divide your problem in smaller pieces, so that you can focus on the level of abstraction you want to work on.</p> |
| <p>The actor’s behavior will be described with a state machine. A state in turn may contain sub states. This is another possibility to focus on an abstraction level. Take the simple FSM from the blinky actor from the blinky tutorial.</p> |
| <p>Top level:</p> |
| <p><img src="images/020-Blinky15.png" alt="image"></p> |
| <p><em>blinking</em> Sub machine:</p> |
| <p><img src="images/020-Blinky151.png" alt="image"></p> |
| <p>From an abstract point of view there is a state <em>blinking</em>. But a simple LED is not able to blink autonomously. Therefore you have to add more details to your model to make a LED blinking, but for the current work it is not of interest how the blinking is realized. This will be done in the next lower level of the hierarchy.</p> |
| <p>This simple example might give an idea how powerful this mechanisms is.</p> |
| <p>The hierarchical FSM provides a rich tool box to describe real world problems (see <a href="room-concepts.html">Room Concepts</a>).</p> |
| <h4><a href="#layering" name="layering"></a>Layering</h4> |
| <p>Layering is another well known form of abstraction to reduce complexity in the structure of systems. ROOM is probably the only language that supports layering directly as a language feature. Layering can be expressed in ROOM by actors with specialized ports, called <em>Service Access Points</em> (SAP) and <em>Service Provision Points</em> (SPP).</p> |
| <p>The actor that provides a service implements an SPP and the client of that service implements an SAP. The layer connection connects all SAPs of a specific protocol within an actor hierarchy with an SPP that implements the service. From the actor’s point of view, SAPs and SPPs behave almost like ports.</p> |
| <p><img src="images/010-LayerExample.png" alt="image"></p> |
| <p>The example shows a layered model. The layer connections define e.g. that the <em>ApplicationLayer</em> uses the services of the <em>ServiceLayer</em> and the <em>CommunicationLayer</em>. Actors inside the <em>ApplicationLayer</em> that use an SAP for those services are connected directly to the implementation of the services. Layering and actor hierarchies with port to port connections can be mixed on every level of granularity.</p> |
| <h4><a href="#run-to-completion" name="run-to-completion"></a>Run to Completion</h4> |
| <p><em>Run to completion</em> (RTC) is a very central concept of ROOM. It enables the developer to concentrate on the functional aspects of the system. The developer doesn’t have to care about concurrency issues all the time. This job is concentrated to the system designer in a very flexible way. What does <em>run to completion</em> mean: RTC means that an actor, which is processing a message, can not receive the next message as long as the processing of the current message has been finished. Receiving of the next message will be queued by the underlying run time system.</p> |
| <p>Note: It is very important not to confuse <em>run to completion</em> and <em>cooperative multi threading</em>. Run to completion means that an actor will finish the processing of a message before he can receive a new one (regardless of its priority). That does <em>not</em> mean that an actor cannot be preempted from an higher priority thread of control. But even a message from this higher prior thread of control will be queued until the current processing has been finished.</p> |
| <p>With this mechanism all actor internal attributes and data structures are protected. Due to the fact that multiple actors share one thread of control, all objects are protected which are accessed from one thread of control but multiple actors. This provides the possibility to decompose complex functionality into several actors without the risk to produce access violations or dead locks.</p> |
| <h3><a href="#execution-models" name="execution-models"></a>Execution Models</h3> |
| <p>Since from ROOM models executable code can be generated, it is important to define the way the actors are executed and communicate with each other. The combination of communication and execution is called the <em>execution model</em>. Currently the eTrice tooling supports the <strong>message driven</strong>, the <strong>data driven</strong> and a mixture of both execution models. In future releases maybe also a synchronous execution model will be supported, depending on the requirements of the community.</p> |
| <h4><a href="#communication-methods" name="communication-methods"></a>Communication Methods</h4> |
| <ul> |
| <li> |
| <p><strong>message driven</strong> – asynchronous, non blocking, no return value:<br>Usually the message driven communication is implemented with message queues. Message queues are inherently asynchronous and enable a very good decoupling of the communicating parties.</p></li> |
| <li> |
| <p><strong>data driven</strong> – asynchronous, non blocking, no return value:<br>In data driven communication sender and receiver often have a shared block of data. The sender writes the data and the receiver polls the data.</p></li> |
| <li> |
| <p><strong>function call</strong> – synchronous, blocking, return value:<br>Regular function call as known in most programming languages.</p></li> |
| </ul> |
| <p>eTrice currently supports the two former communication methods.</p> |
| <h4><a href="#execution-methods" name="execution-methods"></a>Execution Methods</h4> |
| <ul> |
| <li> |
| <p><strong>execution by receive event</strong>: The message queue or the event dispatcher calls a <strong>receive event</strong> function of the message receiver and thereby executes the processing of the event.</p></li> |
| <li> |
| <p><strong>polled execution</strong>: The objects are processed by a cyclic <strong>execute</strong> call</p></li> |
| <li> |
| <p><strong>execution by function call</strong>: The caller executes the called object via function call</p></li> |
| </ul> |
| <p>eTrice currently supports the two former execution methods.</p> |
| <h4><a href="#execution-models" name="execution-models"></a>Execution Models</h4> |
| <p>In present-day’s embedded systems in most cases one or several of the following execution models are used:</p> |
| <h5><a href="#message-driven" name="message-driven"></a>message driven</h5> |
| <p>The message driven execution model is a combination of message driven communication and execution by receive event. This model allows for distributed systems with a very high throughput. It can be deterministic but the determinism is hard to proof. This execution model is often found in telecommunication systems and high performance automation control systems.</p> |
| <h5><a href="#data-driven" name="data-driven"></a>data driven</h5> |
| <p>The data driven execution model is a combination of data driven communication and polled execution. This model is highly deterministic and very robust, but the polling creates a huge performance overhead. The determinism is easy to proof (simple mathematics). The execution model is also compatible with the execution model of control software generated by Tools like Matlab(TM) and LabView(TM). This model is usually used for systems with requirements for safety, such as automotive and avionic systems.</p> |
| <h5><a href="#synchronous" name="synchronous"></a>synchronous</h5> |
| <p>The synchronous execution model could also be called <em>function calls</em>. This model in general is not very well suited to support the <em>run to completion</em> semantics typical for ROOM models, but could also be generated from ROOM models. With this execution model also lower levels of a software system, such as device drivers, could be generated from ROOM models.</p> |
| <hr> |
| <p><a href="#navbar">back to top</a> <span class="version pull-right">version 2.x</span></p> |
| </div> |
| </div> |
| </div> |
| |
| <!-- jQuery (necessary for Bootstrap's JavaScript plugins) --> |
| <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script> |
| <!-- Include all compiled plugins (below), or include individual files as needed --> |
| <script src="js/bootstrap.min.js"></script> |
| <script src="js/metisMenu.min.js"></script> |
| <script src="js/prettify.js"></script> |
| <script src="js/custom.js"></script> |
| </body> |
| </html> |
