MARTE is structured around two main concerns, one to model the features of real-time and embedded systems and the other to annotate application models so as to support analysis of system properties. These are shown by the MARTE design model package in following figure, and the MARTE analysis model package, respectively. These two major parts share common concerns with describing time and the use of concurrent resources, which are contained in the shared package called MARTE foundations. A fourth package contains the annexes profiles defined in MARTE, as well as a predefined model libraries that may used by modelers to denotes their real-time and embedded applications.
The profile is structured around two concerns, one to model the features of real-time and embedded systems and the other to annotate application models so as to support analysis of system properties. These are shown by the MARTE design model package in following figure, and the MARTE analysis model package, respectively. These two major parts share common concerns with describing time and the use of concurrent resources, which are contained in the shared package called MARTE foundations. A fourth package contains the annexes profiles defined in MARTE, as well as a predefined model libraries that may used by modelers to denotes their real-time and embedded applications.
 

Figure 1. Architecture of the MARTE profile

In support of the modelling of real-time and embedded systems, as for the aforementioned structure of this specification, MARTE offers the following four fundamental pillars:
 
Pillar1: QoS-aware Modeling

• HLAM: for modeling high-level RT QoS, including qualitative and quantitative concerns.
• NFP: for declaring, qualifying, and applying semantically well-formed non-functional concerns.
• Time: for defining time and manipulating its representations.
• VSL: the Value Specification Language is a textual language for specifying algebraic expressions.

Pillar 2: Architecture Modeling

• GCM: for architecture modeling based on components interacting by either messages or data.
• Alloc: for specifying allocation of functionalities to entities realizing them.

Pillar3: Platform-based Modelling

• GRM: for modeling of common platform resources at system-level and for specifying their usage.
• SRM: for modeling multitask-based design
• HRM: for modeling hardware platform

Pillar4: Model-based QoS Analysis

• GQAM: for annotating models subject to quantitative analysis.
• SAM: for annotating models subject of scheduling analysis.
• PAM: for annotating models subject of performance analysis.

Note: (NFPs = Non-Functional Properties , GRM = Generic Resource Modeling, GCM = Generic Component Model, Alloc = Allocation modeling, RTEMoCC = RTE Model of Computation & Communication, SRM = Software Resource Modeling, HRM = Hardware Resource Modeling, GQAM = Generic Quantitative Analysis Modeling, SAM = Schedulability Analysis Modeling, PAM = Performance Analysis Modeling, VSL = Value Specification Language, RSM = Repetitive Structure Modelling).