前面几篇一直在讲管道、路由和缓冲区。这些机制在 EDS 模式下仍然存在。我接着想弄清的是：既然发送接收主线没有换，CFE_EDS_ENABLED 到底改变了什么？为什么独立运行 SB，还要带上 EdsLib、MissionLib 和一套生成数据库？

把这一层展开，也就能把之前学过的 EDS 与这次的 SB 阅读接起来。这里尤其要区分“用 EDS 描述的 native 消息在 SB 中流转”和“把对象打包成线上字节”，两者不能仅凭一个 EDS 开关混为一谈。

在前几篇里，发送应用直接调用 SB API，消息就进入了接收管道。这很容易带来一个新疑问：源码中为什么还需要一个 CFE_SB_TaskMain()？所有应用的消息是否都要先经过这个任务转发？

我把这两条路径分开以后才看清楚：应用调用的发送函数在调用者的执行上下文里完成路由和投递；SB 自己的任务处理的是给 SB 的管理请求。它也使用管道和订阅机制，算是软件总线上的一个服务使用者。

第一次只看接口时，CFE_SB_ReceiveBuffer() 很像“从队列拿一块内存，用完再释放”。源码里的行为却有一个很重要的差别：应用拿到的是 SB 管理的借用指针，管道会记住这次交出的缓冲区，下一次接收时再放下前一次引用。

如果这一点没想清楚，很容易把接收指针丢给另一个线程，或者调用名字看起来很合适的 CFE_SB_ReleaseMessageBuffer()。这两种写法都需要重新检查所有权。

管道和订阅准备好以后，发送端只需要调用一次 CFE_SB_TransmitMsg()。接口看起来短，里面却同时处理了消息校验、内存池分配、路由查找和多个队列的投递。

我读这条路径时最先想弄清两件事：两个订阅者是否各复制一份消息，以及函数返回成功究竟能说明什么。把这两件事放在前面，再看 TransmitTxn_* 这组函数，调用链就比较容易串起来。

SB 最容易记住的接口是 CreatePipe、Subscribe、TransmitMsg 和 ReceiveBuffer。但只记调用顺序，还是解释不了几个问题：管道已经创建，为什么没有消息？订阅究竟改了哪张表？一个管道订阅两种消息时，深度和消息限额又怎样一起生效？

这篇先把发送前需要准备的东西理清。沿着“创建一个管道，再订阅一条消息”的过程，可以同时看见 SB 的资源管理、锁的边界和路由关系。

前面整理 EDS 和 PUS 时，关注点主要是“一条消息表达什么、怎样编码”。继续往下读 cFS，会碰到另一个问题：消息已经定义好了，运行中的几个应用怎样把它交给彼此？谁创建任务，谁维护队列，换一个操作系统后又该改哪一层？

我这次把阅读范围收到了 cFE 的 Software Bus，也就是 SB。不过在钻进发送和接收函数之前，先把 cFS、cFE、OSAL、PSP 这几个名字放回各自的位置。否则看到一个 OS_QueueCreate()，很容易把业务通信、cFE 服务和操作系统实现混在一起。