Common Data Model
IRI: https://w3id.org/altium/cdm/
The Altium Common Data Model (CDM) describes the entities of the Altium platform, such as projects, components, BOMs, tasks and users, grouped into bounded contexts. For each class it records what the entity is, how it relates to other entities, how it is identified by a GRID (Global Resource ID) and, where one exists, its type in the Altium 365 API.
Platform 12 entities · 2 resources
Design 10 entities · 2 resources
Library Management 19 entities · 3 resources
Collaboration 2 entities · 1 resource
Configuration Management 3 entities
Procurement 4 entities · 4 resources
System Design 2 entities · 10 resources
System Design - System Data Model 2 entities · 15 resources
Requirements 7 entities · 1 resource
Device Model 1 entity · 23 resources
Software 6 entities · 2 resources
Bounded Contexts
Platform
Models the platform-wide objects that other bounded contexts build on: organizations (Company Accounts) with their users and user groups, Workspaces with their members and groups, applications, event subscriptions, and Renesas 365 solutions with their releases. It also holds the lifecycle definitions (with their stages and states) and revision naming schemes that govern Workspace Items. Organization-level data is managed in the Company Dashboard; Workspace-level configuration, including these definitions and schemes, is managed from Altium Designer or the Workspace browser interface.
| Name | Description | Platform API |
|---|---|---|
| Application | TBD | GloApp |
| Event Subscription | TBD | GloEvtSubscription |
| Lifecycle Definition | Defines the set of states that an entity can transition through in its lifecycle. This definition clarifies what stage a revision of an entity has reached in its 'life' and what it can be safely used for. Different entities can have different lifecycle definitions assigned to them. | DesLifeCycleDefinition |
| Lifecycle Stage | A named stage that groups lifecycle states in a lifecycle definition using the Advanced management style (e.g. Design, Prototype, Production), indicating how far a revision has progressed in its development. Stages can be linked to the levels of the revision naming scheme. Definitions using the Simple style have states and transitions but no stages. | DesLifeCycleStage |
| Lifecycle State | A named point in an Item Revision's lifecycle (e.g. Planned, New From Design, In Production, Obsolete) that shows its status from a business perspective. Each state's properties include whether revisions in that state are shown in the Explorer panel and whether they may be used in designs; a revision moves to another state only through a transition defined in its lifecycle definition. | DesLifeCycleState |
| Revision Naming Scheme | Defines the format of Revision IDs for the Items that use it: one to three levels (e.g. Model, Prototype and Revision), each with its own format, separator and minimum width. The scheme is chosen per Item when the Item is created and cannot be changed after its first release. It is distinct from the Item Naming Scheme, which determines the Item ID rather than the revision's ID. | DesRevisionNamingScheme |
| Organization | An Altium customer organization, represented by its Company Account. The Company Account brings together the organization's users and groups of users, its purchased licenses and the Altium 365 Workspaces created for it, along with a company profile (e.g. name, logo and website). Administrators manage it through the Company Dashboard. | GloOrganization |
| Solution | A Renesas 365 solution: the main, top-level object of a Renesas 365 Workspace, which brings together the system design (an ESD document), PCB projects and software projects of one system. System designs and software projects both push their changes to the solution's System Data Model (SDM) and pull from it; Altium Designer can open a solution's PCB projects and pull SDM changes into them. | SolSolution |
| Solution Release | Release of the Solution. This is a formal immutable artifact, representing a specific state of the Solution at the time of release. | |
| User | A person identified by a global Altium Account, the identity used for signing in to Altium services. A user can be registered in an organization's Company Account, either added by an administrator or admitted through an approved join request, and can then be given access to licenses through the Company Account's user groups. Access to a Workspace is granted separately, by making the user a member of that Workspace. | GloUser |
| User Group | A named group of users within an organization's Company Account, managed in the Company Dashboard. Licenses can be allocated to a group so that its members can use them, and the Group Administrators system group gives its members Dashboard administration rights. A user can belong to any number of groups, groups can be provisioned from an identity provider via SCIM, and they are distinct from the groups defined inside a Workspace. | GloUserGroup |
| Workspace | The top-level entity that plays a role of a closed environment for other entities (members, projects, components, etc.). | DesWorkspace |
| Workspace Group | Workspace Group represents a logical collection of users within a workspace, used to manage access control, permissions, and collaboration roles across projects and data assets. | DesWorkspaceGroup |
| Workspace User | A person's membership in a particular Workspace, connecting their Altium Account to that Workspace and to the Workspace groups they are assigned to. Members can come from the organization that owns the Workspace or from other organizations, and inviting an outside user does not add them to the owning organization. People who only have a project shared with them (External Share guests) are not members. | DesWorkspaceUser |
Design
Models design projects stored in a Workspace, including multi-board and harness projects, with their parameters, variants and releases, the manufacturing packages shared from releases, project templates with their revisions, rule checks run against projects, and design reviews of projects. It corresponds to Workspace projects in Altium 365 and Altium Designer, from project creation through to design release.
| Name | Description | Platform API |
|---|---|---|
| Design Review | A structured assessment of a design project, carried out by assigned Reviewers on a fixed snapshot of its design and concluded by the Initiator's decision, which leaves a traceable record of the review. | |
| Harness Project | Harness Project defines the design of a cable and wiring harness as a standalone yet integrable artifact, capturing connectors, wires, splices, and pin-to-pin mappings required to implement electrical interconnects between boards and system elements. | DesProject |
| Manufacturing Package | A read-only package that contains a subset of Project Release artifacts that is typically shared with an external party for the purposes of manufacturing the board (e.g. Manufacturing Package may contain fabrication/assembly files required by the factories, but not the sources of the project) | |
| Multiboard Project | Multiboard Project represents the coordinated design of multiple interconnected PCB projects assembled into a single system, capturing both their logical interconnects and physical arrangements. | DesProject |
| Hardware Project | A design project stored in a Workspace, normally under its built-in version control, such as a PCB project. It groups the design documents that together define one implementation of a product, along with its project parameters and variants; it is the source from which releases are made and from which Managed BOMs can be created. | DesProject |
| Project Parameter | A name/value parameter defined at the level of a design project. It is either a Workspace-side (server-side) parameter, kept with the project in the Workspace and editable only there, or a design-side parameter, kept in the project file (e.g. *.PrjPcb) and editable in Altium Designer. Both kinds appear in the project options and can be used as special strings in design documents. | DesProjectParameter |
| Hardware Project Release | Project Release captures an immutable snapshot of a PCB design project at a specific point in its lifecycle, packaging all design data, outputs, and metadata required for manufacturing, assembly, and downstream processes. | DesRelease |
| Project Template | A reusable starting point for new design projects that bundles the documents, files and project settings a team wants to apply again and again. A project created from a template receives the template's documents and its project options. | DesProjectTemplate |
| Project Template Revision | An immutable revision of a project template. | DesProjectTemplateRevision |
| Hardware Project Variant | A design variant of a project: a named variation of the same base design that is assembled with a different set of components. Within a variant, each component can be fitted, not fitted, fitted with varied parameters, or replaced by an alternate part, and the variant can define its own variant-level parameters. Assembly variants share one bare board, whereas fabrication variants also change overlay information and so need a different board. | DesWipVariant |
| Rule Check | Rule check definitions that can be executed against a project to validate design integrity and compliance with specified constraints. | RuleCheck |
| Rule Check Execution | Execution of a rule check against a project to validate design integrity and compliance with specified constraints. | RuleCheckExecution |
Insights
Models insights: findings, detected asynchronously, that give the user insight within one domain area and can be followed up by tasks. There are two concrete kinds. A part insight concerns one Workspace part, may be informed by BOMs or design projects, and occurs in BOM releases, project releases or component revisions. A design insight concerns a design and is part of a design review.
| Name | Description | Platform API |
|---|---|---|
| Design Insight | An insight within the design domain: a finding, detected asynchronously, about the design under review in a design review. It is always part of that review and can be followed up by tasks. | DesWorkspaceInsInsight |
| Part Insight | TBD | DesWorkspaceInsInsight |
Library Management
Models the components stored in a Workspace and their revisions, the symbols, footprints, parameters, datasheets and part choices that make them up, and the component templates they can be created from. It also covers manufacturer parts in the Workspace part catalog, part requests, and reusable design content such as reuse blocks, managed sheets, and schematic and PCB snippets. It corresponds to Workspace components and design reuse in Altium Designer and Altium 365.
| Name | Description | Platform API |
|---|---|---|
| Component | Component represents a uniquely identifiable electronic part, defined by both its abstract design intent and its concrete realizations in manufacturing and supply. | |
| Component Parameter | A named parameter of a Workspace component, holding a value and, optionally, a data type. Parameters can be inherited from a component template or added directly to the component; a template can give them unit-aware (e.g. Farad, Ohm) or dictionary-defined types. | DesComponentParameter |
| Component Revision | Revision of a Component. | DesComponent |
| Component Template | Component Template defines a reusable blueprint for creating and managing electronic components with consistent parameters, metadata, and lifecycle policies. | DesComponentTemplate |
| Component Template Revision | A revision of a Component Template: the template definition, stored as a *.CMPT document, saved into the Workspace at one point in time. A component revision can be linked to a specific template revision, from which it takes its predefined parameters, models and settings. | DesComponentTemplateRevision |
| Datasheet | Datasheet represents a technical document associated with a Component or Part, providing authoritative specifications, electrical characteristics, and manufacturer information. | DesDatasheet |
| Footprint | Footprint represents the physical layout definition of a Component on a PCB, specifying pad geometry, land patterns, and mechanical clearances required for assembly and manufacturing. | |
| Footprint Revision | A revision of a Footprint: the PCB footprint as saved into the Workspace at one point in time, with its own lifecycle state. Editing a Workspace Footprint saves it into the next revision; components that still link to an earlier revision become out of date until they are updated. | DesFootprint |
| Managed Sheet | A schematic sheet, with its components and wiring, stored in a Workspace so that it can be reused in other designs. A managed sheet may itself contain further managed sheets beneath it in a hierarchy, and the Workspace lets you trace which components it contains and which designs use it. | |
| Managed Sheet Revision | A revision of a Managed Sheet: the schematic sheet as saved into the Workspace at one point in time. A design uses a specific revision, so when the sheet is revised, existing designs can be updated to the new revision or kept on the previous one. | |
| Part | A manufacturer part, identified by manufacturer and part number, as held in the Workspace's Part Catalog together with the supplier parts through which it is sold. Workspace components reference manufacturer parts through their Part Choices. | DesPart |
| Part Choice | One entry in a component's Part Choice list: a manufacturer part, rather than a specific supplier, that may be used to implement the component, bringing with it the offers of the suppliers that sell it. Entries are ranked automatically by availability, price and lifecycle, and users can override the order with their own rank; the top preferred entry is used as the component's part choice in a BOM. | |
| Part Choice List | The list of Part Choices for a component: the manufacturer parts that may be used to implement it on the assembled board. In the product the list is associated with the component and seen by all of its revisions; when part choice revision control is enabled, changing the list saves a new component revision. | |
| Part Request | Part Request represents a formal demand from a designer to introduce a new Component or Part into the managed library, typically triggered when an item is not yet available in the workspace. | |
| PCB Snippet | A selection of circuitry from a PCB design, including its components and routing, saved so that it can be placed in other PCB documents. A snippet saved to a Workspace is revised like other Workspace items; snippets can also be kept in local folders. | |
| PCB Snippet Revision | A revision of a PCB snippet as saved into the Workspace at one point in time. Editing a Workspace snippet saves it into the next revision. | |
| Reuse Block | A reusable section of a design stored in a Workspace, typically combining schematic circuitry with its PCB representation; a block can also be schematic-only or PCB-only. Placing a reuse block on a schematic sheet brings its PCB content into the board design when changes are transferred through an ECO. | DesReuseBlock |
| Reuse Block Revision | A revision of a Reuse Block: its schematic and/or PCB content as saved into the Workspace at one point in time, with its own lifecycle state. Editing a reuse block saves it into the next revision. | DesReuseBlockRevision |
| SCH Snippet | A selection of circuitry from a single schematic sheet, including its components, saved so that it can be placed in other designs. A snippet saved to a Workspace is revised like other Workspace items; snippets can also be kept in local folders. | |
| SCH Snippet Revision | A revision of a schematic snippet as saved into the Workspace at one point in time. Editing a Workspace snippet saves it into the next revision. | |
| Symbol | Symbol represents the logical schematic view of a Component, defining its electrical interface, pins, and attributes used to express circuit intent in design schematics. | |
| Symbol Revision | A revision of a Symbol: the schematic symbol as saved into the Workspace at one point in time, with its own lifecycle state. Editing a Workspace Symbol saves it into the next revision; components that still link to an earlier revision become out of date until they are updated. | DesSymbol |
Collaboration
Models collaboration on Workspace content: comment threads attached to a point, object or area of a document, the individual comments in each thread, and tasks that assign work to users or teams. In the product, comments are placed on documents of Workspace projects (e.g. through the Comments and Tasks panel in Altium Designer), and tasks are tracked on the Tasks page of a Workspace.
| Name | Description | Platform API |
|---|---|---|
| Comment | A single entry in a comment thread: either the initial comment, pinned to a point, an object or an area of a design document (or to a BOM line), or a reply to it. A comment can mention people or groups using @, and it can be assigned to a Workspace member as a task, either when it is posted or later by converting it. Only the author can edit or delete a comment, and deleting the initial comment also deletes its replies. | DesComment |
| Comment Thread | Comment Thread represents a structured discussion linked to a specific design object, document, or workspace item, capturing feedback, decisions, and context directly within the collaborative design environment. | DesCommentThread |
| Task | Task represents a discrete unit of work assigned to a user or team within the design workflow, used to track progress, responsibility, and completion status for design, review, or management activities. | DesTask |
Configuration Management
Models environment configurations, which restrict the Altium Designer working environment of the Workspace members they target to approved configuration data, together with schematic templates and their revisions stored as Workspace Items. In Altium 365 this corresponds to environment configuration management through the Team Configuration Center.
| Name | Description | Platform API |
|---|---|---|
| Environment Configuration | A named set of configuration data items that the Workspace members it targets are allowed to use in Altium Designer. The items are revisions of Workspace Items of supported content types (e.g. schematic, BOM, project and Draftsman templates, output job files and layer stacks, plus at most one Altium Designer Preferences revision), and the same item can be used by several configurations. Administrators define configurations in the Workspace's Team Configuration Center (TC2) and assign them to Workspace groups, called roles there; when a group member signs in to the Workspace from Altium Designer, each controlled area of the design environment is restricted to the chosen configuration's items. | |
| Schematic Template | A schematic template stored as a Workspace Item. When applied to a schematic sheet, the template sets the sheet's size, its graphics such as a title block, and its sheet-level parameters, so that a team's schematics look consistent. The template content is kept in successive revisions of the Item, and environment configurations can reference those revisions to control which templates designers may use. | |
| Schematic Template Revision | One revision of a Workspace schematic template Item, holding the template as saved at that point, e.g. from Altium Designer with Save to Server or uploaded from a *.SchDot file. Editing the template saves the result into the next revision, and environment configurations list template revisions, rather than the Item itself, as their configuration data. |
Procurement
Models bills of materials: BOMs kept in a Workspace and worked on in the BOM Portal (managed and consolidated BOMs) with their releases, global BOMs, which are not tied to a Workspace, and BOM lines with their alternate and substitute parts and the issues found when a BOM is analysed. It corresponds to the Altium 365 BOM Portal.
| Name | Description | Platform API |
|---|---|---|
| BOM Issue | A problem found when a BOM is analysed, usually against a particular BOM line: for example an unknown part number, a duplicated designator, or a part that is deprecated, low in stock or not compliant with a standard such as REACH. The level at which each kind of check reports (Fatal Error, Error or Warning, or No Report to ignore it) is configurable, and an individual issue can be waived. | BomIssue |
| BOM Item | One line of a BOM: its designators and quantity, the primary manufacturer part used for it (identified by manufacturer and manufacturer part number), and any alternate parts recorded for that line. A line can be linked to a Workspace component that lists its part among its Part Choices, and BOM checks report issues against individual lines. | BomItem |
| BOM Item Alternate | An alternate part recorded for one BOM line: another manufacturer part that could be used instead of the line's primary part. Alternates belong to the individual BOM line rather than applying across BOMs. They can come from an uploaded BOM file, be added by hand, or be filled in automatically from the linked component's Part Choices and from suggested alternates, and an alternate can be promoted to become the line's primary part. | BomItemAlternate |
| BOM Item Substitute | Substitute is a replacement of a part by another within an individual BOM. | BomItemSubstitute |
| BOM Release | A static snapshot of a Managed BOM's data, saved under a release name with an incremented revision number and optional notes. The BOM Portal makes a release automatically when a Managed BOM is first created and again once its data has been mapped, and further releases can be made whenever needed. Each release moves through its own lifecycle states (by default Draft, Approved and Obsolete), and a Workspace can be configured to block releasing while the BOM has Error or Fatal Error issues. | BomRelease |
| Consolidated BOM | Consolidated BOM represents the aggregated bill of materials across one or more Projects or variants, combining all required Parts into a single, unified view for procurement and manufacturing. | BomWip |
| Global BOM | Global BOM represents a bill of materials that resides outside of any workspace, on Octopart, where users can create, edit, collaborate on and share it with others. | |
| Managed BOM | A bill of materials kept in a Workspace and worked on in the BOM Portal, where its lines are enriched with manufacturer and supplier data for review and procurement. It can be created from a design project (one of its variants or releases) or uploaded as a CSV/XLS file from any source. A Managed BOM made from a project keeps a link to that project, so it can be updated when the project changes, either in place or as a new revision; snapshots of its data at a point in time are kept as BOM releases. | BomWip |
Supply
Models the supply catalog: manufacturer parts with their aggregated sourcing data and distributor offers, the companies acting as their manufacturers or distributors, and the vendor-specific part family hierarchy, along with catalog content such as reference designs, evaluation kits, solution templates and software projects. Part, offer and company data correspond to the supply chain data that Octopart aggregates and serves through the Octopart API.
| Name | Description | Platform API |
|---|---|---|
| Company | Supply Company represents an organization in the electronics supply chain. Depending on context it is the manufacturer of a Part or a distributor (or broker) that sells it. | SupCompany (Nexar) |
| Evaluation Kit | A vendor evaluation kit in the supply catalog, described by its associated devices, its reference designs (including a main one) and the software projects compatible with it. In Renesas 365 an eval kit can be linked to a solution, and the browser can connect to the kit over J-Link. | SupEvalKit |
| Offer | Supply Offer represents a specific commercial listing of a Part from a supplier, detailing price breaks, stock availability, lead times, and ordering conditions at a given point in time. | SupOffer (Nexar) |
| Part | Supply Part represents a market-available instance of a manufactured Part, providing aggregated sourcing data such as pricing, stock levels, and supplier offers. | SupPart (Nexar) |
| Part Family | A manufacturer's grouping of parts in the supply data, where the kind of family is vendor-specific (e.g. Series or Family). Part families form a hierarchy: a family has either child families or, at the lowest level, Part Groups. Families sharing the same parent are usually close alternatives to one another. | SupPartFamily |
| Part Group | A leaf of the part family hierarchy in the supply data, holding the parts that belong to it together with group-level information such as its manufacturer, overview, key features and documents. Groups sharing the same parent family are usually close alternatives to one another. | SupPartGroup |
| Reference Design | An example design published in the supply catalog, bringing together its design files (e.g. schematics and layouts), documentation and the parts it uses. In Renesas 365 a reference design can be imported into a solution, which adds it to the Workspace as a PCB project linked to that solution. | SupRefDesign |
| Software Project | A software project published in the supply catalog, together with the evaluation kits it is compatible with. In Renesas 365 it can be imported into a solution with a compatible eval kit; the import places the project in the Workspace and links it to the solution (see sft_SoftwareProject). | SupSoftwareProject |
| Solution Template | A publisher's template for a solution, held in the supply catalog. It brings together catalog software projects, evaluation kits and a system design (ESD) source, and users can clone it. | SupSolutionTemplate |
Customization
Models ways to customize and automate a Workspace: process workflows, and scripts with their versions, their executions and the event raised when an execution completes. In the product, each workflow belongs to a process definition that a Workspace administrator creates and manages in the Workspace browser interface.
| Name | Description | Platform API |
|---|---|---|
| Script | TBD | GloScrScript |
| Script Execution | TBD | GloScrScriptExecution |
| Script Execution Completed | TBD | |
| Script Version | TBD | GloScrScriptVersion |
| Workflow | A process workflow of an Altium 365 Workspace: the workflow that belongs to a process definition and steps designers through an everyday design process (e.g. requesting a new part, a design review or creating a new project). Workspace administrators build process definitions in the Process Workflow Editor, grouped by process theme (Part Requests, Project Activities, Project Creations), and activate them; each started instance of a process follows the workflow and creates tasks for the users whose action is needed to move it on. | DesWorkflowDefinition |
System Design
Models the Electronic System Design (ESD) document of a Renesas 365 solution: a system-level block diagram of functional blocks with their key (hardware) and software components, ports and parameters, the connections between blocks, and entries for the hardware and software projects that implement the system. It corresponds to Electronic System Design in a Renesas 365 Workspace; a Global ESD has the same content outside of any Workspace.
| Name | Description | Platform API |
|---|---|---|
| Connection | A connection line in an ESD document representing an interconnection between functional blocks (e.g. signals passed between the interfaces of two devices), drawn directly between blocks or between their ports. In the editor a line can also start or end on other objects or in free space; this model records each end as a functional block and port (see system_Endpoint). | |
| Endpoint | One end of a connection in an ESD document, identified by the functional block and the port where the connection line starts or ends. | |
| ESD Document | A system-level block diagram document used in a Renesas 365 solution (listed there as a System Design project) to describe the architecture of the system at a functional level. It holds functional blocks with their hardware components, software components and ports, the connections between blocks, and blankets through which parts of the design can be linked to PCB or software projects. Pushing to and pulling from the solution's System Data Model (SDM) for the system design is done from the ESD document. Blankets are not modelled as a separate entity here (see MF-068). | SysEsdDocument |
| Functional Block | Represents a logical block within an ESD document (e.g., MCU subsystem, LED driver block) that stands for a function, operation or device of the system, including parameters, key components, software components, ports, and associations. In the ESD editor a functional block can also contain other blocks; this nesting is not modelled here. | |
| Global ESD | An Electronic System Design that resides outside of any Workspace. It has the same content as an ESD document but is not part of a solution. | |
| Hardware Project | An entry of an ESD document for a PCB design project (des_Project) that implements part of the system, listing the functional blocks that project covers. In the ESD editor a PCB project can be linked to a hardware blanket (which can be placed around functional blocks), and each project can be linked to at most one blanket in a document. | |
| Key Component | A key component of a functional block in an ESD document, shown in the editor as a hardware component (e.g. a Renesas RA MCU chosen with the RA Explorer). Its device configuration (ports, package information, peripherals and pin assignments) can be viewed and edited on the hardware component. Software components of the block reference their parent key component. Its SDM counterpart is system_SdmHardwareComponent. | |
| Parameter | Name–value parameter associated with functional blocks, ports, or other system design resources. | |
| Port | An interface of a functional block in an ESD document (e.g. the I2C interface of an MPU), placed inside the block's boundaries; connection lines between blocks can start and end at ports. It is a logical interface, distinct from dm_Port, which is a physical port of a device. | |
| Port Association | TBD | |
| Software Component | Functional in nature, abstracted from but connected to logical implementation. | |
| Software Project | An entry of an ESD document for a software project (sft_SoftwareProject) that implements part of the system, listing the software components that project covers. In the ESD editor a software project can be linked to a software blanket, and each project can be linked to at most one blanket in a document. |
System Design - System Data Model
Models the System Data Model (SDM) of a Renesas 365 solution and its versions, each combining a functional model with device, hardware and software models, plus metadata recording who created a version and with which application, and client-specific metadata (e.g. for ESD, Altium Designer or e² studio). The ESD document and e² studio push changes to and pull changes from the SDM, and Altium Designer pulls it into hardware projects.
| Name | Description | Platform API |
|---|---|---|
| Authoring Application | Identifies the application used to create a system model version. | |
| Domain Metadata | Captures metadata specific to a particular client (e.g., ESD, AD, E2Studio). | |
| Connection | Represents a connection between functional blocks. | SysSdmConnection |
| Device Model | Represents a device model within the system design. | SysSdmDeviceModel |
| Endpoint | Represents an endpoint of a connection. | SysSdmEndpoint |
| Functional Block | Represents a logical block within a system functional model. | SysSdmFunctionalBlock |
| Functional Model | Captures the functional aspects of the system design, focusing on the behavior and interactions of functional blocks. | SysSdmFunctionalModel |
| Hardware Component | Represents a hardware component / part. | SysSdmHardwareComponent |
| Hardware Model | Captures the hardware components and their interactions within the system design. | SysSdmHardwareModel |
| Port | Represents a port within a system design. It is a logical interface of a functional block, distinct from dm_Port, which is a physical port of a device. | SysSdmPort |
| Software Component | Represents a software component instance and its dependencies. | SysSdmSoftwareComponent |
| Software Model | Captures the software components and their interactions within the system design. | SysSdmSoftwareModel |
| Software Specification | The "blueprint" for a software component. Captures the identity and classification of the software independently of any specific instance. | SysSdmSoftwareSpecification |
| Software Stack Instance | Represents a software stack instance and its dependencies. | SysSdmSoftwareStackInstance |
| System Model | A high-level system model that captures the overall system architecture, crossing boundary between functional and logical domains (e.g., hardware and software). | SysSdmSystemModel |
| System Model Version | A specific version of a system model, capturing the state of the system design at a particular point in time. | SysSdmSystemModelVersion |
| System Model Version Metadata | Metadata associated with a specific version of a system model, capturing provenance information. |
Requirements
Models requirements and their revisions, the specifications that group them, baselines approved for execution, change requests, the requirements projects that scope this work, and verification cases that provide evidence against requirements; most of its classes are experimental. It corresponds to requirements management and verification & validation in the Altium 365 Requirements Portal.
| Name | Description | Platform API |
|---|---|---|
| Requirement Artifact | TBD | |
| Requirements Project | The orchestration space for capturing, evolving, and validating requirements scoped to a product, program increment, or regulatory engagement. | |
| Requirement | A single, testable statement of intent or constraint that governs a solution or process outcome. | |
| Requirement Baseline | A version-managed release of a specification or subset of requirements approved for execution. In the product this corresponds to a released specification (Release Specification). It is not what the product calls a baseline: in the Requirements & Systems Portal (Legacy), a baseline is a named bookmark for a point in time (e.g. a design review) that is used to compare how requirements and values have changed. | |
| Requirement Change Request | Structured workflow item proposing additions, updates, or removals of requirements. | |
| Requirement Revision | An immutable snapshot of a requirement statement at a specific revision. | |
| Requirement Specification | A curated collection of requirements scoped to a program, domain, or release horizon. | |
| Verification Case | A planned verification procedure or test that produces objective evidence against requirements. |
Device Model
Models an embedded device (e.g. an MCU), which the CDM calls a digital twin: its processors; its address map with memories, registers, bit fields and their enumerated values; its peripherals with their instances, modes and configurations; and its pins and ports with the alternative functions of each port. A configured device model filters the full model to one device configuration, which in the product is edited on a hardware component in an ESD document.
| Name | Description | Platform API |
|---|---|---|
| AddressBlock | Address block with start, size, and optional registers and peripherals. | DmAddressBlock |
| AddressMap | Address map for the device including memory and peripheral regions. | DmAddressMapModel |
| AddressSegment | A contiguous region of the device's memory map. Each segment can represent either a memory or a peripheral region. | DmAddressSegment |
| ConfiguredDeviceModel | A digital twin of an embedded hardware device as configured for a specific use-case. It exposes the device model filtered to specific device configuration. | DmDeviceModelAsConfigured |
| FieldEnum | An enumerated value for a register field. | DmAmFieldEnum |
| FullStackDeviceModel | A digital twin of an embedded hardware device. It exposes the full device model, including interfaces, peripherals, and ports. | DmFullStackDeviceModel |
| Memory | A memory entry within an address block. | DmAmMemory |
| Peripheral | A single peripheral definition, including its instances and properties. | DmPeripheral |
| PeripheralConfiguration | A concrete configuration for a peripheral role, containing pin multiplexing details. | DmPeripheralConfiguration (not in Platform API snapshot) |
| PeripheralInstance | A concrete instance of a peripheral (e.g., SCI0), including available modes. | DmPeripheralInstance |
| PeripheralMode | A specific mode that a peripheral instance can fulfill, | DmPeripheralMode |
| PeripheralParameter | A parameter associated with peripheral instance configuration. | DmPeripheralParameters (not in Platform API snapshot) |
| PeripheralPinConfig | A specific pin multiplexing configuration within peripheral configuration. | DmPeripheralPinConfig (not in Platform API snapshot) |
| PeripheralPinDependencyConfig | A pin dependency to port mapping entry within peripheral configuration. | DmPeripheralPinDependencyConfig (not in Platform API snapshot) |
| Pin | A physical pin on the device. | DmPin |
| Port | A physical port on the device, with its functions, configurations, and connections. | DmPort |
| PortConfiguration | A specific configuration for a port. | DmPortConfiguration |
| PortConfigurationDependency | A dependency describing how a configuration value maps to GPIO or alternate function usage. | DmConfigDependency |
| PortConfigurationEnumValue | An enumerated value for a port configuration. | DmConfigEnumValue |
| PortConnection | A connection from this port to another component or signal. | DmPortConnection |
| PortFunction | A specific function that a port can perform. | DmPortFunction |
| Processor | Represents a physical processing core. Defining endianness and clock frequency allows the system to determine if the hardware can meet the computational and data-ordering requirements of a use-case. | |
| Register | A hardware register within an address block. | DmAmRegister |
| RegisterField | A bit field within a register. | DmAmRegisterField |
Software
Models the embedded software of a Renesas 365 solution: software projects with their releases and build artifacts, device configurations (with revisions) and their pin assignments, and AI models. In Renesas 365 the software project is the software part of a solution, edited in the built-in Web IDE or in e² studio; a device configuration there also covers the ports, package information and peripherals of a hardware component.
| Name | Description | Platform API |
|---|---|---|
| AI Model | AI model artifact in context of a workspace | |
| Build Artifact | TBD | |
| Device Configuration | The configuration of a device (e.g. an MCU placed as a hardware component in an ESD document), covering its ports, package information, peripherals and pin assignments. It is viewed and edited on the hardware component in the ESD document, and the pin functions it defines can be pulled from the solution's SDM onto the pins of the associated component in a hardware project in Altium Designer. | SftDevCfgDeviceConfiguration |
| Device Configuration Revision | TBD | SftDevCfgDeviceConfigurationRevision |
| Pin Assignment | The assignment of a function to one pin of a device, identified by pin number and name. When a hardware project pulls changes from the solution's SDM, pin functions from the device configuration are added to or removed from the pins of the associated component. | |
| Pin Assignment Model | The set of pin assignments of a device, one part of its device configuration alongside ports, package information and peripherals. | |
| Software Project | The software part of a Renesas 365 solution, developed in the built-in Web IDE (based on the Theia framework) or in e² studio; it can also be created with an external repository type. In the solution's ESD document it can be linked to a software blanket, and generating a board support package (BSP) from that blanket pushes the SDM and applies the changes to the linked project, creating the project first if none exists yet. | SftSoftwareProject |
| Software Release | TBD |
Over-the-Air Updates
Models over-the-air (OTA) firmware and software updates: devices with the packages installed on them, fleets that group devices, packages with their version, size, checksums and target hardware, deployments that request packages to be rolled out to a device or fleet, and the deployment results that record the outcome on each targeted device. All classes are experimental.
| Name | Description | Platform API |
|---|---|---|
| Deployment | Deployment represents the request for an OTA update that assigns packages to the ECUs of its target, either a single device or all devices of a single fleet. It records what was requested, not how it was carried out: the outcome on each targeted device is a separate Deployment Result, which refers to the deployment. Provider-specific scheduling and cancellation restrictions are defined by the corresponding API profile. | |
| Deployment Assignment | Deployment Assignment assigns a package to the ECUs with a given hardware identifier. Deployment requests may name packages only; the provider then resolves the hardware identifier from the package and the target device's ECUs. | |
| Deployment Result | Deployment Result is the outcome of a deployment on one target device, from the time the device is addressed by the deployment, before its update is created. It is kept apart from the deployment, which records the request: the request is fixed when it is created, while the result is updated from the reports of the device as the update progresses. A device deployment has one result; a fleet deployment has one result per device of the fleet. | |
| Device | Device represents a physical unit registered for OTA updates. A device consists of one primary ECU and optional secondary ECUs, and may belong to fleets. | |
| Fleet | Fleet represents a named group of devices managed and updated together. | |
| Package | Package represents one version of a software package registered for OTA deployment. A package is identified by its name and version; the version list of a package is the set of packages sharing the same name. | |
| Package Hash | Package Hash is a checksum of a package binary, used for Uptane target metadata. |
Core
Holds the abstract foundations shared by every bounded context: the base classes Entity (specialised as Artifact and Activity), Resource and Event; the mixins that add annotations such as GRID, maturity and API type; shared slots such as id and name; and the abstract relations (e.g. part of, input of, derived from) that domain relations specialise. It is not a product area and has no product documentation of its own.
| Name | Description | Platform API |
|---|---|---|
| With GRID | Mixin that adds a GRID annotation slot to a class. | |
| With Maturity | Mixin that adds a maturity annotation slot indicating the lifecycle readiness level. | |
| With Platform API | Mixin that adds API type annotations: platformAPI names the Altium 365 Platform API GraphQL type; nexarAPI names the Nexar (Octopart) GraphQL type for supply-chain entities served by Nexar rather than the Platform API. | |
| With Vault | Mixin that adds a vault content type annotation to a class, indicating how its content is stored in the platform vault. | |
| With Vault Link | Mixin that adds vault link parent, child, and type annotation slots for tracking hierarchical vault relationships. |