TeamcenterKnowledge

Skills

Innexis Ae Model Xml

Skill innexis-ae-model-xml. Author the Innexis Architect Explorer analysis model (the AR-PACKAGE XML the AE engine consumes) - its AUTOSAR-shaped schema, the HW-SW-MAPPING element that actually answers "can this electronics carry this software", the hard architecture limits, and the mapping from Teamcenter/Cameo system elements. Use when generating or hand-editing an AE .xml, sizing an AE architecture, or planning a TC-to-AE transform.

The file the AE engine validates and simulates. Schema at D:\Innexis_AE\SystemExplorer\config\XSD_Schema\AE_XSD_schema.xsd ("Ae XSD Schema Version 2"), 188 elements, 254 complex types, no namespace. A 135-page generated reference is at SystemExplorer\docs\InnexisArchitectExplorerXSDSchema_app.pdf, but the XSD itself is far more compact to read.

It is an AUTOSAR-shaped schema with Siemens hardware extensions. Single root AR-PACKAGE.

Document order is a fixed xs:sequence

AR-PACKAGE
└── ELEMENTS                        (maxOccurs unbounded)
    ├── Simulation-Time             value + unit {s|ms|us|ns}
    ├── SENDER-RECEIVER-INTERFACE*  the data contracts
    ├── APPLICATION-SW-COMPONENT-TYPE*   SWCs: PORTS + INTERNAL-BEHAVIORS
    ├── SWC-CUSTOM-BEHAVIOR*        operation sequences, custom C hooks
    ├── PRE-BUILT-APPLICATION*      <PATH DEST="..."> to a real ELF
    ├── Network-Topology            InterECU_communication: CAN-BUS / Eth-Switch
    ├── ECUs{1,100}                 → SoCs → AXI/Ethernet/UCIe, Chiplet*, CPU_Cluster, Generic_Hardware*
    ├── HW-SW-MAPPING*              the allocation
    └── Analysis                    which analyses to enable, per SoC

Emit them in that order or schema validation fails.

References are name paths, and names ARE the identity

There are no UUIDs in this file. Everything is a DEST attribute holding a path built from <SHORT-NAME name="..."/> values:

/SRI_1/RandomData_1
/SWC_0/default/Runnable_Entity_1
/ECU_0/SOC_0/Chiplet_0/CPU_0

⇒ For any generator, name uniqueness and stability is a correctness requirement, not a tidiness one. Two elements sharing a short name silently produce a model that validates and means something else.

The three parts that matter

Software is a real task model

<APPLICATION-SW-COMPONENT-TYPE>
  <SHORT-NAME name="SWC_0"/>
  <PORTS><P-PORT-PROTOTYPE><SHORT-NAME name="CP_2"/>
    <PROVIDED-INTERFACE-TREF DEST="/SRI_1"/></P-PORT-PROTOTYPE></PORTS>
  <INTERNAL-BEHAVIORS><SWC-INTERNAL-BEHAVIOR>
    <SHORT-NAME name="default"/>
    <RUNNABLES><RUNNABLE-ENTITY>
      <SHORT-NAME name="Runnable_Entity_1"/>
      <DATA-WRITE-ACCESS><VARIABLE-ACCESS>
        <SHORT-NAME name="FOP_1"/>
        <ACCESSED-VARIABLE><AUTOSAR-VARIABLE-IREF>
          <PORT-PROTOTYPE-REF DEST="/SWC_0/CP_2"/>
          <TARGET-DATA-PROTOTYPE-REF DEST="/SRI_1/RandomData_1"/>
        </AUTOSAR-VARIABLE-IREF></ACCESSED-VARIABLE>
      </VARIABLE-ACCESS></DATA-WRITE-ACCESS>
    </RUNNABLE-ENTITY></RUNNABLES>
    <EVENTS><TIMING-EVENT>
      <SHORT-NAME name="TimingEvent_1"/>
      <START-ON-EVENT-REF DEST="/SWC_0/default/Runnable_Entity_1"/>
      <PERIOD value="100" unit="ms"/>
    </TIMING-EVENT></EVENTS>
  </SWC-INTERNAL-BEHAVIOR></INTERNAL-BEHAVIORS>
</APPLICATION-SW-COMPONENT-TYPE>

A runnable is triggered by a TIMING-EVENT (with PERIOD) or a DATA-RECEIVED-EVENT. That is enough to schedule. Without a trigger there is nothing to analyse.

Interface payloads are typed Array-of-uint8 No_Of_Bytes="n" or Array-of-float No_Of_Elements="n", each either Random-Values-generated (optionally with a Data-Range min/max) or Fixed-values-generated Default-Value. For Generic_Hardware, the schema documents that only Array-of-uint8 should be used, with random data in range 0..255.

Hardware is parameterised to the core

CPU_Cluster carries an Operating-System (Nucleus_RTOS, or Linux with Buildroot_File_System / Ubuntu_File_System) and a family:

  • ARMV7: CortexM7
  • ARMV8: CortexA53, CortexA57, CortexA72, CortexR52
  • ARMV9 (AFM): AFM-CortexA510, AFM-CortexA710, AFM-CortexA720

with CoresPerCluster and Frequency. Interconnect is AXI-BUS (width, frequency), ETHERNET-INTERFACE, and UCIe-INTERFACE with a full D2D_Configuration (LINK_WIDTH, LINK_FREQUENCY, PROTOCOL_CONV_LATENCY, CHIPLET_LINK_LATENCY, LOGICAL_IF_DELAY, PHYSICAL_IF_DELAY). Generic_Hardware models an accelerator with its own operation sequence including NN primitives (CONVOLUTION, TRANSPOSED-CONVOLUTION, MAX-POOL, AVG-POOL, BATCH-NORMALIZATION, LOG-SOFTMAX, HARDMAX) plus POWER-PARAMETERS.

HW-SW-MAPPING is the question

<HW-SW-MAPPING ClusterRef="/ECU_0/SOC_0/Chiplet_0/CPU_0">
  <Core-Runnable-Mapping CoreId="0" RunnableRef="/SWC_0/default/Runnable_Entity_1"
                         Load="1000" Priority="7"/>
</HW-SW-MAPPING>

Also Core-PrebuiltApplication-Mapping and Cluster-PrebuiltApplication-Mapping for real binaries.

What Load and Priority actually are (read the schema, do not assume)

EXERCISED, from the XSD annotations. Both attributes are use="required".

Attribute Type Schema documentation
Load xs:unsignedInt "The number of CPU cycles used as synthetic load"
Priority xs:unsignedByte, 1..99 (no documentation)

⚠ The schema carries two differently-cased elements: Core-Runnable-Mapping (line 1440, under AeHwSwMappingType, the one the tutorials use) and Core-runnable-Mapping (line 840, under AeCpuCore, attributes DEST/Load/priority lowercase). Do not mix them up.

⇒ Load is cycles, not a percentage or a utilisation. AE is a synthetic-load scheduling simulator unless you feed it a real binary through PRE-BUILT-APPLICATION. The fidelity of any answer it gives is exactly the fidelity of the cycle counts you supplied.

Sourcing them correctly

Cycles are an implementation property of compiled code on a target ISA. They are correctly absent from Teamcenter system elements; that is not a gap to paper over. Sources in fidelity order:

  1. Measured from real code, via PRE-BUILT-APPLICATION with a real ELF. Highest fidelity. ⚠ On this installation that route validates only on Linux clusters (established by the jpo-f35 stage7-innexis-vsi work).
  2. Authored as an explicit engineering parameter in Teamcenter, unit cycles, on the function, human-owned and versioned. See tc-parameters-units.
  3. A stated WCET or budget figure, labelled as such.

⇒ A generator must have NO DEFAULT for Load. If the cycle count is absent, refuse to emit that mapping and name the runnable. The corpus is the argument: all 42 Core-Runnable-Mapping entries across all 11 shipped tutorials use Load="1000". One value, everywhere. A default does not stay a default; it becomes the number everyone quotes.

Priority is derivable defensibly by rate-monotonic assignment from the PERIOD already in the model: shorter period, more urgent. Optimal for fixed-priority scheduling of independent periodic tasks, and you can state exactly what you did.

⚠⚠ UNRESOLVED: which direction is more urgent? 1..99 matches the Linux RT convention (higher = more urgent), but Nucleus RTOS, the OS in most tutorials, conventionally uses lower = more urgent. The shipped corpus does not disambiguate: 41 mappings use Priority="7", exactly one uses "6", and that single mixed case (Real_Workload_Simulation_and_Analysis_using_LTTng, two runnables on one core at 6 and 7) states no intent. Getting this backwards inverts every scheduling result while still validating and still producing plausible numbers. Settle it by experiment before trusting a rate-monotonic assignment: one core, two runnables, equal periods, cycle counts that over-subscribe the core, then read which one starves in analyze.

Network topology binds software interfaces to a physical bus, which is the other half:

<Network-Topology><InterECU_communication>
  <CAN-BUS CAN-FD="true">
    <SHORT-NAME name="CanBus_0"/><BaudRate value="500000"/>
    <INTERFACE-TREF DEST="/SRI_1"/><INTERFACE-TREF DEST="/SRI_0"/>
  </CAN-BUS>
</InterECU_communication></Network-Topology>

Hard limits to size against

From the Release Notes (documented, not measured):

  • Overall system up to 90 SoCs per the manual. ⚠ The XSD annotation says 100, and both ECUs and SoCs carry maxOccurs="100". The manual and the schema disagree; use 90.
  • SoC: up to 4 chiplets; each chiplet up to 32 Generic_Hardware and a single CPU cluster.
  • CPU cluster: up to 8 cores.
  • Nucleus: max 64 runnables per CPU cluster per chiplet.
  • Chiplet/SoC numbering must start at 0 and be contiguous.
  • Linux forces CPU frequency to 1 GHz.
  • Nucleus analysis is not available on AFM CPUs; AFM cores are not supported by Low Level Exploration.
  • M7 and R52 cannot do inter-chiplet communication.
  • A SoC with more than 12 cores may cause simulation errors on a Windows host.

Mapping Teamcenter / Cameo system elements to this

Source AE XML
logical block / system element (software) APPLICATION-SW-COMPONENT-TYPE
function allocated to a block RUNNABLE-ENTITY + TIMING-EVENT period from its rate
signal / interface SENDER-RECEIVER-INTERFACE + VARIABLE-DATA-PROTOTYPE
port on a block P-PORT-PROTOTYPE / R-PORT-PROTOTYPE
physical/EE item (ECU, board) ECUs / SoCs
processor part + attributes CPU_Cluster + family / CoresPerCluster / Frequency
bus from the E/E architecture Network-Topology / CAN-BUS / Eth-Switch
software-to-hardware allocation HW-SW-MAPPING / Core-Runnable-Mapping

Three gaps that are not "electronics detail" and will not come from a TC publish:

  1. Trigger semantics and rate per runnable. Without it nothing schedules.
  2. Payload size per interface (No_Of_Bytes / No_Of_Elements).
  3. Load and Priority.

(1) and (2) belong upstream in Cameo, but note the Cameo→TC connector carries a fixed property set, so extra SysML detail may not survive the publish. The realistic route is a post-publish enrichment pass writing them as TC parameters. (3) is a budget number someone owns.

The Capella side of the same data

The AE model is also stored inside the .capella file as kitalpha viewpoint extensions:

<ownedExtensions xsi:type="AeAnalysis:RunnableEntity" id="...">
  <events xsi:type="AeAnalysis:TimingEvent" id="..." .../>

Full set observed: ECU, Soc, Chiplet, CpuCluster, CpuCore, RunnableEntity, TimingEvent, DataReceivedEvent, DataAccess, CoreRunnableMapping, SwcPartialMapping, DirectPortConnection, RandomData, SWAnalysis, HWAnalysis.

⇒ The .xml is a projection of the Capella model, not an independent input. Write the .xml if you only want analysis; write the .capella if a human must open and extend it. See capella-headless-authoring.

Worked examples that ship

SystemExplorer\Tutorials\ has 11 complete projects. Most useful:

Tutorial Shows
Simple_Example smallest complete model, 8 runnables on a 4-core A53
Inter-ECU_Communication_via_CAN_FD CAN FD at 500 kbaud, bus utilisation and latency
Real_Workload_Simulation_and_Analysis_using_LTTng ships a real operations.elf; PRE-BUILT-APPLICATION route
Chiplet-Based_SoC_Model_for_Sensor_Fusion_and_AI_Workflows custom silicon + NN operators

⚠ Simple_Example/readme.txt claims "2 clusters, 2 cores each". The XML has one cluster of 4 (CortexA53 CoresPerCluster="4", CoreIds 0-3). Trust the XML, not the readme.

Related

  • innexis-ae-headless to run validate as the acceptance gate for anything generated here.
  • capella-headless-authoring for the Capella-side authoring route.

Generated from skills/innexis-ae-model-xml/SKILL.md in the tc-automation-skills library, which is the canonical copy and also serves as the agent skill set for Teamcenter work.