Skip to content

Design Notes

Benjamin Riggs edited this page Feb 7, 2020 · 2 revisions

AMM Data & Power Transport Selection

Early in the development of AMM, a variety of options for providing both data connectivity and power delivery were researched. A very early proof-of-concept version used USB-C connectors for combined data & power transport. As various options were investigated, the discovery of both DDS and the – at that time – new IEEE 802.3bt draft standard provided a robust solution to enable combined power & data transmission along with high-level data transfer Quality of Service (QoS) provisions.

Comparisons to Other Solutions

USB

While USB can provide both high data transmission rates as well as sufficient power (with the USB Power Delivery specification), the use of USB would require substantially more development of the would-be 'core computer' for AMM (fulfilling the same role as the Network Manager). OS drivers, message routing, data broadcast, etc. would all need to be either implemented from scratch, or repurpose existing software not designed for data handling via USB. Additionally, a separate wireless solution would have to have been created. In contrast, using UDP/IP(v4) over Ethernet or Wi-Fi enables the use of widely available and thoroughly robust networking technologies.

CAN Bus

The use of a CAN bus and dedicated power transmission lines was also investigated. It was determined that a CAN bus would be a poor fit for the desired high-level architecture of AMM as a whole. A core concept of AMM is that the data being transmitted between modules be at an abstraction level that makes sense to medical practitioners. This should facilitate better module design because the semantic understanding of module behavior can be more easily evaluated by examining data transmissions. Because of this, inter-Module data transmissions are fairly verbose, and, in some cases, far exceed the data transmission rates of a CAN bus.

Rare / Proprietary Solutions

Because a core tenet of AMM is to make the standard as open as possible, along with a desire to reduce the barrier of entry to new Module creators, vendor-specific solutions were not considered. Furthermore, extremely niche solutions as well as solutions without widely-available components were also dismissed.

Clone this wiki locally