常规设置部分定义适用于整个 exOS 目标机系统的参数，如通信设置或特定功能的开关。
•IP 地址/主机名
IP 地址/主机名是 AR 用于连接目标系统的地址。 安装 exos-server时 ，在选择用于 exOS 的接口时也会打印出该 IP 地址。IP 地址 默认设置为 192.168.137.2， 因为这是 Hypervisor 配置内部网络上默认的 Linux 主机地址。
•日志记录
exOS 目标配置中的日志记录设置定义了 exOS 的一般日志记录设置。
o级别
系统启动时的初始日志级别。可设置为 ERROR、 WARNING、 SUCCESS、 INFO 或 DEBUG。默认级别为 SUCCESS。
o信息类型
信息类型允许对已设置的日志级别进行额外过滤。每种信息类型都可以单独打开或关闭。
▪用户消息：启用/禁用用户应用程序特定信息。
▪DMR 消息：启用/禁用由数据集消息路由器生成的系统消息。
▪冗长信息：启用/禁用高度冗长的信息消息。此设置还将在 AS 软件构建过程中输出更多信息 - 参见 技术软件包构建错误
请注意，结合 使用DEBUG级别 并打开系统消息和详细消息会产生大量日志输出，因此不适合在循环数据传输时激活。在这种情况下，系统各层次发布数据的所有事件都会被记录，这可能会导致日志系统超载，造成信息丢失。
部署机制的信息始终会被记录。
o目的地
AR 中记录仪输出的设置。
▪易失性（DRAM）：日志信息存储在 DRAM 中。重新启动 PLC 后，日志信息将丢失。
▪剩余 (USRRAM)：日志信息存储在 USRRAM 中。只有在冷启动 PLC 时才会删除。
▪永久 (USRROM)：日志信息存储在 USRROM 中。日志信息始终被保存。 注意： 该设置可能会影响 CF 卡的使用寿命。
默认设置 为易失性（DRAM）。
•部署
在这里，可以 打开 或 关闭一般部署机制 ，指的是与 exos-server 的连接。
默认设置为 "开"， 因为假定目标系统上有一个可以接收和安装组件的 exos 服务器。在这种情况下，exos-服务器将接收 " 组件" 部分 配置的所有引用的 exOS 组件 。
如果将 "部署 "设置为 "关闭"，则会禁用与 exos-server 的连接，这意味着 AR 与 exos-server 之间不会发生任何交互。这也意味着之前部署到目标上的任何组件都将保留并继续运行，直到目标系统重启。
将 "部署 "设置为 " 移除 "基本上意味着 "清理目标系统"。在这里，与目标系统上 exos-server 的连接会被建立（ 与打开时 一样 ），但目标系统上的所有组件都会被移除。 与此同时， 由于目标系统上没有运行与 AR 通信 的组件，数据连接 被隐式强制为 关闭（要在 不 部署的情况下启用 数据连接， 必须将 部署 设置为 关闭）。
•数据连接
数据连接 可以 打开 或 关闭。
默认情况下， 数据连接 为 "开"，这基本上意味着 Linux 上运行的服务能够利用与 AR 的数据通信。
在启用数据连接的情况下，有许多设置将在下一节中介绍。
o时间同步
exOS 的时间同步功能负责将 AR NETTIME 发送到 Linux。它还将 Linux 数据集消息路由器的执行 与 Linux 上的阻塞调用（等待 AR） 同步 。 有关此主题的更多信息，请参阅 时间同步 章节。
关于同步机制的简短描述是，AR 数据集消息路由器 向 Linux 数据集消息路由器 发送 NETTIME 和预计到达时间。如果该到达时间在可配置的预期精度范围内，则会根据当前的预测误差调整 NETTIME 值，并将其作为新的 NETTIME 参考值发送给 Linux 中的应用程序。
该 NETTIME 消息也是同步应用程序执行的机制，这些应用程序 在exos_datamodel_process()中阻塞 NETTIME 消息 。 Linux 上的 数据集消息路由器 与 AR 之间的这种交互 是同步执行的基础，即
使 NETTIME 精度不是在每次交互中都能达到，Linux 上的所有应用程序仍会使用最后一次 "良好 "的 NETTIME 进行更新，以便同步执行，并通过 exos_datamodel_get_nettime() 函数 为所有应用程序提供一个推断的 NETTIME 值 。该函数还提供了一个 in_sync 位，用于检查应用程序的同步状态。
时间同步有以下设置：
▪连接
时间同步的连接设置。这些字段（端口、共享内存）是自动填充的，只有在有明确需要时才可更改。
▪精度
配置的 NETTIME 同步精度（质量），单位为微秒。基本上，它是估计的 Linux 时间戳为达到同步状态所需的精度。如果 AR 和 Linux 之间的通信抖动较大，则可能需要提高精度。对于共享内存，精度通常可设置为 100us。
o日志记录
数据连接具有从整个系统的各种程序中收集日志信息并将其收集到中央日志记录器的功能。如果数据连接已打开，则上述一般记录仪设置也适用于远程记录仪。
它具有在源头过滤日志信息的功能，也就是说，如果当前过滤级别/类型不适用，应用程序就不会发送信息。这样可以确保在生产中尽量减少带宽使用（例如，只显示ERROR、WARNING 和 SUCCESS 消息），并且在需要深入研究某种行为的根本原因时，应用程序中仍会保留 DEBUG 消息。
在运行期间，可通过 AR 的ExLogConfig 功能块或 exos_log_change_config() C-API 函数更改级别和消息类型（过滤 ） 。有关日志功能的更多信息，请参阅 exos_log API Reference。
有关如何在运行时读取和操作日志功能的更多信息，请参阅 ExApi Logger一章 。
▪连接
日志系统的连接设置。这些字段（端口、共享内存）是自动填充的，只有在有明确需要时才可更改。
The General settings section defines parameters that apply to the whole exOS Target system such as communication settings or switching specific functionality on or off.
•IP address/hostname
The IP address / hostname is the address which Automation Runtime uses to reach the target system. When installing the exos-server, this IP address is also printed out when selecting the interface used for exOS. The IP Address is set to 192.168.137.2 by default, as this is the default Linux host address on the internal network of a Hypervisor configuration.
•Logging
The Logging settings in the exOS Target configuration define the general logging settings for exOS.
oLevel
Initial log level at startup of the system. Can be set to ERROR, WARNING, SUCCESS, INFO, or DEBUG. Default level is SUCCESS.
oMessage types
Message types allow to apply filtering additional to the set log level. Each message type can be individually switched on or off.
▪User messages: Enable/disable user-application specific messages.
▪DMR messages: Enable/disable system-generated messages from the Dataset Message Router.
▪Verbose messages: Enable/disable highly verbose informational messages. This setting will also output more information during Automation Studio build - see Technology package build errors
Note that the combination of Level DEBUG and switched on System messages and Verbose messages will generate a huge amount of log outputs and is not suited to be activated while cyclic data transmission is active. In this case, all events for publishing data at all levels of the system are logged, and this can potentially overload the logging system causing messages to be lost.
Messages from the deployment mechanism are always logged.
oDestination
Settings for the Logger output in Automation Runtime.
▪Volatile (DRAM): Log messages are stored in the DRAM. They are lost with a reboot of the PLC.
▪Remanent (USRRAM): Log messages are stored in the USRRAM. They are only deleted with a cold-start of the PLC.
▪Permanent (USRROM): Log messages are stored in the USRROM. They are always persisted. Note: Be aware that this setting might influence the life cycle of the CF card.
The default setting is Volatile (DRAM).
•Deployment
Here, the general deployment mechanism can be switched On or Off, referring to the connection towards the exos-server.
This is by default set to On as it is assumed that there is an exos-server present on the target system which can receive and install components. In this case the exos-server will receive all referenced exOS Components configured in the Components section.
If the Deployment is set to Off, the connection towards the exos-server is disabled, meaning that no interaction takes place between AR and the exos-server. This also means that any components previously deployed to the target will remain there and keep running until the target system reboots.
Setting the Deployment to Remove basically means "clean up the target system". Here, the connection towards the exos-server on the target system is established (as with On), but all components on the target system are removed. At the same time, the Data connection is implicitly forced to Off, as no components are running on the target system to communicate with AR (to enable Data connection without Deployment, the Deployment must be set to Off).
•Data connection
The Data connection can be switched On or Off.
By default, the Data connection is On, which basically means that services running on Linux are able to utilize the data communication with AR.
In case the data connection is enabled, there are a number of settings which are described in the following section.
oTime synchronization
The exOS time synchronization handles the delivery of the AR NETTIME to Linux. It also synchronizes the execution of the Linux Dataset Message Router with a blocking call on Linux (waiting for AR). See more on this topic in the Time synchronization chapter.
The short description of the synchronization mechanism is that the AR Dataset Message Router sends the NETTIME to the Linux Dataset Message Router together with an estimated arrival time. If this arrival time lies within the configurable expected precision, the NETTIME value is adjusted with the current prediction error and sent out to the applications in Linux as a new NETTIME reference.
This NETTIME message is also the mechanism that synchronizes the execution of the applications, which are blocking for the NETTIME message in exos_datamodel_process(). This interaction between the Dataset Message Routers on Linux and AR are the base for the synchronized execution, and even though the NETTIME Precision is not met at every interaction, all applications on Linux are still updated with the last "good" NETTIME, in order to synchronize the execution, and have an extrapolated NETTIME value available for all applications via the exos_datamodel_get_nettime() function. This function also provides an in_sync bit to check the synchronization state from the application.
Time synchronization has the following settings:
▪Connection
Connection settings for the time synchronization. These fields (Port, Shared memory) are automatically populated and should only be changed if there is an explicit need to do so.
▪Precision
Configured precision (quality) of the NETTIME synchronization given in microseconds. Basically, it is the required precision that the estimated Linux timestamp should achieve in order to reach a synchronized state. If there is high jitter in the communication between AR and Linux, the precision might need to be increased. For shared memory, the precision can usually be set in the range of 100us.
oLogging
The Data connection comes with the functionality to collect log messages from various programs throughout the system and collect those at a central logger. If the Data connection is switched on, the general Logger settings described above also apply to the remote logger.
It has the functionality to filter out log messages at the source, meaning messages are not sent from the applications if the current filter level/type does not apply. This ensures minimal bandwidth utilization in production (for example, where only ERROR, WARNING, and SUCCESS messages are shown) and still have DEBUG messages left in the applications if a situation would require to look deeper into the root cause of a certain behaviour.
The Level and Message type (filtering) can be changed during runtime via the ExLogConfig function block from AR, or via the exos_log_change_config() C-API function. See more on the logging functionality in the exos_log API Reference.
See the chapter ExApi Logger for more information on how to read out and manipulate the logging functionality during runtime.
▪Connection
Connection settings for the logging system. These fields (Port, Shared memory) are automatically populated and should only be changed, if there is an explicit need to do so.