在 " 组件" 部分，将部署的 exOS 组件分配给 exOS 目标。此外， 还 可以配置数据集消息路由器的 设置 以及使用 exOS API的 服务数据交换 。
•常规
o心跳
心跳 "与 "超时 "设置一起使用，其中 "心跳 "是参与者之间发送 "保持 "信息的 "ping 间隔"。每个超时间隔最好有四次心跳。心跳设置适用于服务与 数据集消息路由器之间的连接 ，以及 AR 与 Linux 数据集消息路由器 之间的连接 。
o超时
服务与 数据集消息路由器之间 以及 AR 与 Linux 数据集消息路由器 之间 接收心跳的监视时间 。如果在给定的超时间隔内未收到心跳，连接将被视为 "断开"，并在服务中触发相应的状态更改回调。
oDMR 任务类别
此选项配置 AR 数据集消息路由器的任务类别 ，因此也 配置 Linux 上数据集消息路由器的周期时间 。 请注意，较短的周期时间会给 Linux 系统带来较高的负载。默认设置为 TC#2，建议将所有需要与 Linux 紧密同步的 exOS 程序分配到相同的任务类别。
•组件 (们)
在此列表中输入要部署到目标的 exOS 组件。exOS 组件配置中未在此列表中引用的组件既不会在目标上部署，也不会启动。
o配置
可在下拉框中选择 exOS 组件配置中定义的 exOS 组件。这些组件包含在目标系统上实际部署和启动的信息。
从配置中的 exOS 组件列表中选择一个新组件时，数据模型将自动由 exOS 组件配置实例引用 的.exospkg 文件 填充 。这样（通过创建 .exospkg 文件），exOS 组件的创建者就能定义组件使用的通信通道（数据模型实例）。有关这方面的更多信息，请参阅 exOS 软件包 章节。
o数据模型
一个 exOS 组件可能由一个或多个服务组成，这些服务在 AR 和 Linux 之间建立连接。其中每个服务都可以实例化数据模型作为通信手段。 数据模型通过其名称进行标识，并 通过 exos_data_model_connect() 代码生成函数 中的 datamodel_instance_name连接到 数据集消息路由器 。为了在 AR 和 Linux 之间为该数据模型实例分配传输机制， 数据集消息路由器会 在 数据模型实例名 和传输系统端点（Linux 主机） 之间创建关系 。
▪实例
每个组件都可以托管通过不同数据模型实例连接的各种服务。该列表包含完整的数据模型及其与 Linux 的相应连接。
•名称
数据模型实例名称。与 提供给 exos_data_model_connect() 函数的数据模型实例名称相对应。
•连接
给定数据模型实例的连接设置。这些字段（端口、共享内存）是自动填充的，只有在有明确需要时才可更改。默认情况下，共享内存名称与数据模型实例名称相同。
In the Components section, exOS Components that are to be deployed are assigned to the exOS Target. Additionally, settings for the Dataset Message Router as well as the data exchange for services using the exOS API can be configured.
•General
oHeartbeat
The Heartbeat goes together with the Timeout setting, of which Heartbeat is the "ping interval" between "keepalive" messages sent between the participants. There should preferably be four Heartbeats for every Timeout interval. This Heartbeat setting applies to the connection between a service and the Dataset Message Router as well as the connection between the AR and Linux Dataset Message Routers.
oTimeout
Surveillance time for receiving heartbeats between services and the Dataset Message Router as well as between the AR and Linux Dataset Message Routers. If a Heartbeat was not received within the given Timeout interval, the connection will be treated as "Disconnected" and corresponding state-change callbacks will be triggered in the services.
oDMR task class
This configures the task class of the AR Dataset Message Router, and therefore also the cycle time of the Dataset Message Router on Linux. Note that small cycle times can create a high load on the Linux system. The default setting is TC#2, and it is advised that all exOS programs that require a tight synchronization with Linux are assigned to the same task class.
•Component (n)
The exOS Components that are to be deployed to a target are entered in this list. Components in the exOS Component configuration that are not referenced in this list are neither deployed nor started on the target.
oConfiguration
exOS Components that are defined in the exOS Component Configuration can be selected in a dropdown box. Those hold the information of what is actually being deployed and started on the target system.
When selecting a new component from the exOS Component list in the Configuration, the Data models are automatically populated by the .exospkg file referenced by the exOS Component configuration instance. In this way (by creating an .exospkg file), the creator of the exOS component has the ability to define which communication channels (data model instances) are used by the component. See more on this in the exOS Package chapter.
oData models
An exOS Component may consist of one or serveral services that establish connections between AR and Linux. Each of those services may instantiate data models as a means of communication. A data model is identified via its name and is connected to the Dataset Message Router via the datamodel_instance_name in the exos_data_model_connect() code generated function. To assign a transport mechanism between AR and Linux for this datamodel instance, the Dataset Message Router creates a relationship between the datamodel_instance_name and the transport system endpoint (Linux host).
▪Instance (n)
Each component can host various services that are connecting via different datamodel instances. This list contains the full list of datamodels and their corresponding connection to Linux.
•Name
Data model instance name. Corresponds to the datamodel_instance_name supplied to the exos_data_model_connect() function.
•Connection
Connection settings for the given datamodel instance. These fields (Port, Shared memory) are automatically populated and should only be changed, if there is an explicit need to do so. By default, the shared memory name is the same as the data model instance name.