Optional is Not an Option
Gerry Tyra - April 2015
Efficient processing of time sensitive data requires that the data be consistent and complete. Given the facilities discussed previously, consistency and completeness can be assured without allowing for optional data fields. Taking the statement further, allowing optional fields is counter productive and should be explicitly excluded.
The current UCI interface, as defined in an XML schema, uses a relatively small number of messages to define a large spectrum of data types. To accomplish this, many fields are listed as being optional. But, by allowing optional fields, the the processing of messages types becomes significantly more complex and less reliable.
This is the part of the yin/yang pair with message derivation and revision being the other side.
Whether a processing unit is called a service, a process or a thread isn't important. The point is that a body of code was designed and implemented to execute a specific operational function. In order to do this, that processing unit must be provided with whatever input it requires. In most practical cases, incomplete data sets are useless. At best an incomplete data set severely compromises performance.
A data set made up of related data should be self consistent in time and space. The position, velocity and acceleration data should be of a similar age, and not very old. At the same time, the engine status should not be old, but it does not necessarily have to be synchronized to the navigation data.
Overhead for Options:
If optional fields are allowed in a message structure, there has to be a mechanism to determine if that field is populated or not. Hence the cost in bandwidth for the optional field is greater than it would be if the field was simply required.
On the sending side, who determines if the field will be populated at all? As a designer, I don't want to waste development and integration time on activities that are not required. And if Systems Engineering slipped up and didn't call out that specific optional fields must be populated, they probably won't be.
On the receiving side, the function may require data contained in optional data fields. If one source provides the data, while another source doesn't, the resulting processing will, at best be more complex than absolutely required, and, at worst never work quit right.
Consider the all too common problem of a new release. The original source application provided all of the data, whether it was flagged as required or optional in the interface. So, the receiving function works properly through integration. But, at a later date, the data source is refactored and some of the optional data fields are no longer populated. Suddenly the output of the receiving application may be producing subtle, or not so subtle, errors. What changed? What was actually critical? A lot of late nights in the integration lab may be in order, with the attendant costs.
Summary - Why Bother?:
Given the ability to revise and derive messages without causing major disruptions to the existing message structure, why take on the headaches and risks or defining optional data fields?