ION-DTN设计原则

ION的设计之初就旨在解决DTN面临的一些约束。约束具体已在上篇博文中介绍：https://blog.csdn.net/hahachenchen789/article/details/83377056

 

设计原则：

1.共享存储（share memory）

由于ION-DTN必须在飞行处理器上运行，它必须被设计成在RTOS中成功运行。许多实时操作系统通过省略对类unix操作系统提供的保护内存模型的支持来改进处理速度：也就是说，所有任务（进程）都可直接访问系统内存的所有区域，实际上所有进程都在内核态运行，而不是在用户态。因此，在设计ION的时候，并没有考虑到对内存的保护。

但是，对所有内存的普遍共享访问不仅可以看作是一种危险，也可以看作是一种机会。将数据对象放在共享内存中是将数据从一个软件任务传递到另一个软件任务的一种非常有效的方法。

ION就是利用这种机会，来实现数据的高效传输。如下图所示：

发送任务接受互斥信号量(互斥量)，以保护共享内存(DRAM或非易失性内存)中的链表，向链表追加数据项，释放互斥量，并给出与链表关联的“信号”信号量，以宣布链表现在不是空的。

接收任务已经挂在链表的相关信号量上，在信号量获取时恢复执行。它获取关联的互斥对象，从列表中提取下一个数据项，释放互斥对象，并继续从发送任务中操作数据项。

 

信号量操作通常非常快，就像在内存中存储和检索数据一样，因此这种任务间数据交换模型对于飞行软件来说是非常有效的。

 

2.零拷贝进程

考虑到ION对共享内存模型的定位，一个进一步提高处理效率的策略就应运而生了。

如果添加到链表中的数据项只是指向大型数据对象的指针，而不是拷贝出的副本，那么我们可以通过消除字节对字节复制大型对象的成本来进一步减少处理开销。

此外，如果多个软件元素需要同时访问同一个大对象，我们可以为每个这样的软件元素提供一个指向对象的指针，而不是它自己的副本（维护一个引用计数，以确保在所有元素放弃它们的指针之前对象不会被销毁）。这在一定程度上减少了ION操作所需的内存数量。

 

3.高度分布式处理

基于共享内存的任务间通信的高效率使得在多个相对简单的流水线任务之间分发ION处理变得很实用，而不是在单个稍微复杂一点的守护进程中本地化它。该机制有几个优点：

a.)每个任务的简单性降低了软件模块的大小，使它们更容易理解和维护，从而在一定程度上减少了错误的发生。

b.)通过生成或终止可配置软件元素的实例，可以在运行时增量地调整ION操作堆栈的范围，而无需增加单个任务的大小或复杂性，也无需在新的配置中停止并重新启动整个堆栈。

c.)任务之间清晰的接口简化了流控制措施的实现，以防止不受控制的资源消耗。

 

4.可移植性

基于这些原则的设计对于许多软件开发人员来说是陌生的，他们可能更适应受保护内存支持的开发环境。例如，在Linux环境中开发软件通常要比在VxWorks 5.4中容易得多。然而，Linux环境并不是ION软件最终必须运行的唯一环境。

因此，ION被设计成易于移植，POSIX接口标准被广泛应用。目前RTEMS可以运行在Linux（Redhat，FeFedora，Ubuntu），FreeBSD，Solaris，VxWorks，RTMES等。