SDO是CANopen协议中最复杂的一部分，带有应答机制，有多种传输方式，并且完整的SDO功能节点需提供1个SDO server和多个SDO client，因此SDO的实现异常困难，协议多种传输方式的解析处理还有迹可循，多个SDO client服务和多个对SDO server的访问的协调就不容易了，这里介绍一种方法——SDO线程来解决。
注意，这里的线程可不是操作系统提供的多线程技术，况且为保证协议栈良好的移植性，在CANopen协议栈核心代码里中也不好去调与操作系统相关的库函数。我们这里的SDO线程只是借鉴了操作系统多线程机制的一套SDO服务处理方法，每个SDO线程表示的是与网络上其他节点建立的一个SDO链接，相当于在两个节点间建立一个SDO通讯路径，其中每个节点都拥有一个对这个路径的描述，在该节点看来好像建立了一个线程来负责这个路径（但决不会真的创建一个系统线程），在通讯过程中双方通过这个路径来交流，SDO通讯结束则释放该线程，每个节点可以同时与多个节点建立多个这样的路径和互不影响，就如同操作系统的线程机制一样的效果。我们知道每建立一个线程都会生成一个描述线程属性的参数表和一些私有数据，类似的，SDO线程的建立也会初始化一个对应的参数和数据结构体——SDO线程参数表，以之来描述这个SDO链接的属性并提供私有通讯数据的存储。
SDO线程参数表可以说是SDO线程的核心，所有SDO线程的建立、删除和SDO通讯都要涉及到这个参数表。参数表内容包括能够描述一个SDO访问过程的所有参数，这里不详述。
一次SDO访问是这样完成的。首先SDO发起节点(SDO client)收集足够的信息，建立一个SDO线程，说白了就是初始化SDO线程参数表，将收集的信息以特定格式放入参数表，形成一帧SDO请求，发送出去。SDO服务节点(SDO server)收到这帧请求，为它建立一个SDO线程，将这帧请求分析分解以获得足够信息来初始化这个SDO线程对应的参数表，然后程序就会按照参数表的描述去执行server的功能收集数据来满足这个SDO请求，然后将收集到的数据形成SDO应答帧返回给SDO client，如果此次请求结束则释放该线程，否则等待下一帧请求到来；SDO client在收到应答后判断该请求是否还有后续请求，无则释放此SDO线程。如果在这个过程中，SDO server 和SDO client所在节点有收到其他节点的SDO请求或需要通过SDO请求其它节点，则新建SDO线程来实现，跟上面的步骤一样，这样就可以实现多个SDO server和SDO client服务都得到实现而互不干扰，相当于双向多线铁路，可比单线爽多了。
该方法已在单片机下实现，效果还不错。
(于2007.11.6)