Designing Around Processing Endpoints

The “traditional” way to ensure that these disparate devices and systems are able to leverage data from one another across a network is to examine the data requirements of each device, and draw one-to-one interfaces between those devices. Once the relationship has been established, the data can be passed between those two devices, likely using direct messaging or a transactional client-server call.

The processing-centric approach requires that both the data-producer and data-consumer know both the existence and location of one another, and use identical data structures and/or user-defined network protocol to exchange the data item.

This approach works, and can be efficient under many circumstances. However, this design also assumes that the network and application-architecture is static and unchanging. If an acquisition radar unit is swapped out for an upgraded model, the targeting computer code has to be adapted to recognize and work with the new hardware. If the radar’s data is in a different format, further code changes and additional testing is required.

That is the case if only two devices are involved. In practice, the radar data might be used by half a dozen or more shipboard systems. Further, it is possible that devices are co-dependent on one another and have embedded stateful semantics in the data they are exchanging. For example, the radar and targeting computers may use data from one another to successively refine initial estimates, or to locate and successively target multiple targets.

Given this complex yet deceivingly straightforward design approach, maintaining these distributed systems throughout their lifecycle can be a significant technical, logistical, and financial challenge. Every upgrade and system modification would, at a minimum, require extensive testing to ensure that changes did not introduce incompatibilities and that system interactions remain consistent. Code changes will be likely.