exOS应用程序接口（数据通信）使用预编译头，以便在不同操作系统和编译器之间通信时补偿不同的字节间距。该标头有以下限制：
▪每个数据集最多 200KB 数据。
数据模型中的单个数据集不能超过这个大小，因为它还会影响AR中内部创建任务的预配置堆栈大小。不过，由于每个数据集都是通过缓冲区传输的，因此发送大于200kB的数据可以通过发送200kB的数据块来实现（数据集消息路由器每个周期至少可以传输5个200kB的数据集，在10ms的任务类中传输速率为640Mbps）。200kB的限制还应从共享内存大小的角度来看，200kB数据集的共享内存大小为ShmSize=4*12*(dataset_size)=9.6MB，这进一步相当于DRAM=2,11*ShmSize[MB]+1,27[MB]=21,5MB的DRAM使用量。
在这种情况下，还需要注意的是，AutomationRuntime中给定任务类的堆栈大小需要增加到（至少）最大数据集的大小。以200kB数据集为例，这意味着堆栈大小（至少）为250kB
•Max 256 datasets per datamodel.
这意味着，exOS在一个数据类型中支持256个独特的结构成员。在大多数情况下，这与TYP文件中声明的成员数量相同，这意味着结构数组不会创建额外的唯一成员。例如，数据类型
BigDataValue : STRUCT
Id : UDINT;
Value : LREAL;
Ack : BigDataAck;
END_STRUCT;
BigData : STRUCT
Values : ARRAY[0..999]OF BigDataValue; (*PUB SUB*)
END_STRUCT;
这将产生以下 7 个可订阅或发布的独特数据集。
{EXOS_DATASET_BROWSE_NAME(Values),{}},
{EXOS_DATASET_BROWSE_NAME(Values[0]),{1000}},
{EXOS_DATASET_BROWSE_NAME(Values[0].Id),{1000}},
{EXOS_DATASET_BROWSE_NAME(Values[0].Value),{1000}},
{EXOS_DATASET_BROWSE_NAME(Values[0].Ack),{1000}},
{EXOS_DATASET_BROWSE_NAME(Values[0].Ack.Id),{1000}},
{EXOS_DATASET_BROWSE_NAME(Values[0].Ack.Latency),{1000}},
如果在TYP文件中发现超过256个唯一数据集，则构建过程的头文件生成器将输出错误信息。
▪同一数据模型只能发布/订阅一个（或全部）唯一的数组元素。
从上面的例子来看，这意味着可以通过browse_nameValues或其中一个索引（如Values[1]或Values[1].Value）发布/订阅所有Values。但是，目前无法从同一数据模型订阅Values[1]和Values[2]。
▪不支持派生类型。
Automation studio .typ 文件支持使用直接派生类型，例如，将 Id_t 声明 为 UDINT，但 exOS 头生成器不支持这种做法。
▪不支持多维数组和从索引 0 以外的任何地方开始的数组。
▪描述字符串的长度不能超过 60kBytes。
预编译标头还声明了数据类型的JSON描述字符串，该字符串将被发送到数据集消息路由器。该描述字符串不能超过60kBytes。另一方面，256个唯一数据集的限制比描述字符串的大小更容易造成限制。
每个应用程序都使用一个预编译的头文件来连接数据集消息路由器。在生成的头文件中，有一个JSON格式的描述字符串，用于建立每个应用程序作为通信结构获得的相同数据模型，并将此通信结构连接到对面的DatasetMessageRouter数据模型实例，同时为通信分配缓冲区。
这方面的限制是，同一系统中的两个应用程序需要有相同的描述字符串。基本上，这意味着数据集消息路由器不会检查JSON结构的内容，只会检查字符串本身是否相同（使用strcmp）。如果来自两个不同应用程序的描述字符串不匹配，则第一个连接获胜，第二个应用程序将收到EXOS_STATE_ABORTED数据模型事件，并带有EXOS_ERROR_CODE_STRING_FORMAT错误。这里需要补充的是，生成的头文件没有时间戳或构建ID，因此只要.typ文件没有更改，重建头文件就不成问题。使用 exOS 构建链 可以避免许多此类问题，因为一个exOS组件的所有相关应用程序都可以同时使用同一个生成的头文件进行构建。
AR和Linux之间在连接时也会进行类似的检查，如果配置不匹配，就会导致EXOS_STATE_ABORTED事件和EXOS_ERROR_SYSTEM_LXI错误。
The exOS API (data communication) utilizes a pre-compiled header in order to compensate for different byte paddings when communicating between different Operating Systems and compilers. This header has the following limitations:
•Max 200kB data per dataset.
A single dataset within the datamodel cannot exceed this size, as it also has an impact on the preconfigured stack sizes of the internally created tasks in AR. As every dataset however is trasmitted via buffers, sending larger data than 200kB can be achieved by sending the data in 200kB chunks (the Dataset Message Router can transmit at least 5 200kB datasets per cycle, giving a transmission rate of 640Mbps in a 10ms taskclass). The 200kB limitation should also be seen in the light of the resulting shared memory size, which is ShmSize = 4*12*(dataset_size) = 9.6MB for a 200kB dataset, which further amounts to DRAM = 2,11*ShmSize[MB] + 1,27[MB] = 21,5MB DRAM usage.
In this case it is also important to note that the stack size of the given task class in Automation Runtime needs to be increased to (at least) the size of the largest dataset. For a 200kB dataset for example, this would mean a stack size of (at least) 250kB
•Max 256 datasets per datamodel.
This means, exOS supports 256 unique structure members within a datatype. This is most of the time the same amount of members as declared in the TYP file, meaning an array of structures does not create additional unique members. For example, the datatype
BigDataValue : STRUCT
Id : UDINT;
Value : LREAL;
Ack : BigDataAck;
END_STRUCT;
BigData : STRUCT
Values : ARRAY[0..999]OF BigDataValue; (*PUB SUB*)
END_STRUCT;
would result in the following 7 unique datasets that can be subscribed or published.
{EXOS_DATASET_BROWSE_NAME(Values),{}},
{EXOS_DATASET_BROWSE_NAME(Values[0]),{1000}},
{EXOS_DATASET_BROWSE_NAME(Values[0].Id),{1000}},
{EXOS_DATASET_BROWSE_NAME(Values[0].Value),{1000}},
{EXOS_DATASET_BROWSE_NAME(Values[0].Ack),{1000}},
{EXOS_DATASET_BROWSE_NAME(Values[0].Ack.Id),{1000}},
{EXOS_DATASET_BROWSE_NAME(Values[0].Ack.Latency),{1000}},
If more than 256 unique datasets are found in a TYP file, the header generator of the build process will output an error.
•Only one unique array element (or all) can be published / subscribed from the same datamodel.
From the example above, this means that either all Values can be published / subscribed to via the browse_name Values, or one of the indexes, like Values[1] or Values[1].Value. However, it is currently not possible to subscribe to Values[1] and Values[2] from the same datamodel.
•Derived types are not supported.
Automation studio .typ files support the usage of directly derived types, for example, declaring an Id_t as UDINT, however this is not supported by the exOS header generator.
•Multidimensional arrays and arrays starting from anything else than index 0 are not supported.
•The description string cannot be longer than 60kBytes.
The precompiled header also declares a JSON description string of the datatype which is sent to the Dataset Message Router. This description string cannot exceed 60kBytes. On the other hand, the limit of 256 unique datasets is more likely to create a limitation than the size of the description string.
Connections from applications via description string
Every application uses a pre-compiled headerfile to connect to the Dataset Message Router. In this generated headerfile there is a description string in JSON format which is used to build up the same datamodel that each application has got as a communication-structure, and connect this communication-structure to the opposite Dataset Message Router datamodel instance together with allocating buffers for the communication.
The limitation in this regard is that two applications on the same system need to have the same description string. Basically, it means that the Dataset Message Router does not check the contents of the JSON structure, only if the string itself is identical (using strcmp). In case there is a mismatch in the description strings from two different applications, the first connection wins, and the second application will recieve an EXOS_STATE_ABORTED datamodel event with an EXOS_ERROR_CODE_STRING_FORMAT error. Here, it might be added that the generated header has no timestamps or build ids, so as long as the .typ file has not changed, rebuilding the headerfile is not a problem. With the exOS build-chain many of these problems can be avoided, as all involved applications of an exOS Component can be built at the same time using the same generated header.
A similar check is performed between AR and Linux when connecting, leading to an EXOS_STATE_ABORTED event with an EXOS_ERROR_SYSTEM_LXI error if there is a mismatch between the configurations.