Profiles

• RXF with stereotypes and Standard Content package used in all RXF products
• RXFMonitor used by the UML Target Debugger in all RXF products
• ArUML_ARXF with stereotypes used in products for both AUTOSAR Classic and Adaptive Platforms.
• ArUML_ARXF_CP specfic for supporting AUTOSAR Classic Platform. It contains stereotypes as well as a package with Standard Content you can use when creating SWCs
• ArUML_CP_miniRTEGenerator with stereotypes and Standard Content package used by the mini-RTE generator
• TC_Environment_ARXF_CP refers to a Helper used to set up TestConductor for the ARXF-CP.
• RXFStereotypesC with properties which effect the code generation
• RXFTypesC with references to C type header files

Stereotypes RXF

• RXF
  This stereotype should be selected for all components generating code for the ARXF-CP:
  • it sets Properties for code generation like use of static Memory management and other details which influence Rhapsody code generation
  • the so-called Simplifier which is part of the Rhapsody code generation tests if an active component has this stereotype set.
• RXFErrorHandler
  This stereotype can be used to implement your own error handler, see section Error handling
  The package rxfErrorHandlerStandardContent in this profile contains a skeleton implementation.

Stereotypes ArUML_ARXF

This profile contains the following stereotypes:

• ArApplicationDataType
• ArAtomicSwc is an abstract stereotype which is the parent of all atomic swc types.
• ArComposition
  This tells the code generator which SWC RTE instances are used.
• ArDataType
• ArInterfaceType
• ArPackage
  This stereotype is used for code generation of packages containing SWCs.
• ArPort
• ArSwcprototype
  This is the Rhapsody instance of an SWC: the counterpart of the RTE instance of an SWC, known as a SWC prototype.

Stereotypes ArUML_ARXF_CP

The profile also contains two packages:

• Standard Content you need when modelling for AUTOSAR Classic Platform
• TaskAllocation which contains stereotypes used to create diagrams to show relations between runnables and OS tasks (AUTOSAR view) and classes and OS tasks (UML view)
  • allocate
    This stereotype is used in relations on a TaskAllocationDiagram to show relation between a runnable or a class and the OS task defined in AUTOSAR.
  • CpTask
    This stereotype is used for an OS task which must be configured in AUTOSAR.
  • TaskAllocationDiagram
    This stereotype allows you to show the relations between classes and OS tasks and runnables and OS tasks.
  • TaskAllocationTable
    

This profile contains the following stereotypes:

• CpClientPort
  Assign this stereotype to an AUTOSAR port on an SW-C to prevent code generation, see Ports.
• CpConnector
  Assign this stereotype to an connector between AUTOSAR Ports on an SW-C.
• CpCSInterface
  Assign this stereotype to interfaces of AUTOSAR Client/Server Ports of an SW-C.
• CpEcu
  This stereotype is used for an ECU which is typically used on a TaskAllocationDiagram
• CpEcu-Abstraction-SWC
  Assign this stereotype to an ECU abstraction SWC connected via AUTOSAR ports to an SW-C to prevent code generation.
• CpEcucModule
  This stereotype is used to identify the OS which holds the CpTasks used on the TaskAllocationDiagram, see OS.
• CpExclusiveArea
  This stereotype is used for exclusive areas which are basically an attribute of an SWC. AUTOSAR Exclusive Areas are used for critical region handlers of the ARXF-CP, see OS Integration.
• CpImplementationDataType
• CpInterrunnableVariable
  This stereotype is used for exchanging the me pointer via an AUTOSAR InterRunnable Variable during initialization.
• CpReceiverPort
  Assign this stereotype to AUTOSAR Receiver Ports on an SW-C.
• CpRTEoperation
  Assign this stereotype to an operation carried out via AUTOSAR ports from your SW-C to another SW-C or Basic Software. This stereotype allows you to use RTE generated APIs for your SW-C.
• CpRTEoperationArgument
  Assign this stereotype to an argument of an RTEoperation
• CpRunnable
  Assign this stereotype to a runnable of a SWC. Its tags category and supportsHoldFlag are for future use.
  • what AUTOSAR specifies as runnable, is what in Rhapsody called the runnableName - a tag of the stereotype CpRunnable.
    

    You may want to override the property C_CG::Operation::PublicName to influence the Rhapsody generated symbol for your runnable which is by default the name of the class and an underscore.

    If you do not want to influence the name of the symbol in your model, but want to do this at the stereotype level, you must modify the profile ArUML_ARXF_CP.
    

  • what AUTOSAR specifies as runnable symbol, is what in Rhapsody called the public name of an operation.
    
  • the tag isInitRunnable must be set for a runnable which serves as ’init’ runnable, see AUTOSAR section Runnable.
    

• CpSenderPort
  Assign this stereotype to an AUTOSAR Sender Ports on an SW-C.
• CpServerPort
  Assign this stereotype to an AUTOSAR Server Ports on an SW-C.
• CpSRInterface
  Assign this stereotype to an interface of AUTOSAR Sender/Receiver Ports of an SW-C or ECU-Abstraction-SWC.
• CpSWC
  When the tag supportsMultipleInstantiation is set to True, generated code will match calls by the RTE with a so-called self pointer, which it passes as argument when calling a runnable of this SW-C
• eventDispatcherActiveClass
  This stereotype is used for a dependency between a runnable used as UML event dispatcher towards an SWC or an active class, see Concurrency. It will instruct the code generator to insert the proper RTE function calls when initializing the active class.
  
  
  
• exclusiveAreaAccess
  This stereotype is used for a dependency between a runnable towards an exclusive area. It will instruct the code generator to insert the proper RTE function calls to enter- and exit the exclusive area.
  See AUTOSAR section Exclusive Area.
  
  
  
• portAccess
  This stereotype is used for a dependency between runnables and AUTOSAR server- and receiver Ports
  • we use a runnable per interface of a server port
    
    
    
  • we use a runnable per receiver port
    
    
    
  The dependency is required for the generation of a proper mini-RTE when using server- and receiver ports.
  The Helper interface2runnable can be used to add a runnable to your model including the dependency and insert sample code in such runnables. See section Ports.
  
  
• SWCDiagram
  This stereotype is used to show the relations between SW-Cs and ECU-Abstraction-SWC using AUTOSAR Ports.
• variableAccess
  This stereotype is used for a dependency between a runnable and an inter-runnable variable for which it has read and/or write access. It instructs the code generator to insert the proper RTE API function calls.
  
  
  

Stereotypes RXFMonitor

• MonitorBase
  This stereotype has the following tags:
  
  • MonitorReceiveCommandBufferSize (default: 32U)
    Maximum size of a command which can be handled by the Monitor when receiving a command from the UML Target Debugger. 32U should be sufficient as long as you do not want to inject events with a huge amount of parameter data.
  • MonitorTaskName (default: "MonitorTask")
    Name of the Monitor task.
  • MonitorTaskPriority (default: RXF_RTOS_TASK_PRIORITY_LOWEST)
    OS priority of the Monitor task.
    The Target Debugger supports the mini-RTE which comes with the product. OS Task details including stack and priority must be specified in an AUTOSAR tool as part of the Basic Software or BSW.
  • MonitorTaskStackSize (default: 1024U)
    The Monitor uses a task to send / receive data. This Tag can be used to define the stack size of the monitor task.
• MonitorIOBase
  This stereotype has the following tags:
  
  • MonitorSendBufferSize (default: 1024U)
    Buffer to collect data while your application is running which are send to the UML Target Debugger host when the monitor task is active.
  • MonitorReceiveBufferSize (default: 32U)
    Buffer which stores received data (commands) from the UML Target Debugger host which are handled inside the monitor task.
• RXFAnimation
  This stereotype has the following tags:
  
  • AnimationType
    You can choose between:
    • RXF_FULL_ANIMATION (default)
      Split the information of a UML event into three packages:
      1. event is put into the message queue
      2. event consumption start
      3. event consumption end
    • RXF_TRACE_ANIMATION
      Event information is send to the Target Debugger host in a single data package at event start to avoid overhead.
  • MaxParallelStates (default: 4U)
    This numeric value should represent the count of parallel states of the statechart with the most parallel states. If this number is too large, unnecessary data is sent to the UML Target Debugger. If this number is too small there is the possibility of losing data. You can find out the number of parallel states by inspecting the count of state attributes of the class which has the suffix "_active".
  • MaxPrintIntObjects (default: 0)
    Number of filtered instances which can send integer values to the UML Target Debugger, see UML Target Debugger Filtering.
    If you do not need this functionality you can switch it of by setting the value to 0.
  • sendParameters (default: True)
    Switch on/off of sending event or operation parameters.
• RXFAnimationMultiTarget
  The standard Embedded UML RXF Target Debugger supports multi-core systems: N/A in this version.
• RXFMonitorForTC and TC_WrapPrivateOperations
  This stereotypes is used in combination with TestConductor.
• RXFMonitorIO_*
  These stereotypes are used when configuring the UML Target Debugger Communication channel.