The role of an ACS model component is to:
Many sets of physically meaningful Values (e.g., heading versus position) used in an ACS are nearly independent of each other, both physically and computationally. There are several reasons that corresponding models of ``macro'' objects such as the Aircraft itself need not, and should not be constructed as single components: Most updates and queries are localized to particular, known, independent aspects of state. The associated mechanics are simpler to arrange for small, independent submodels than a monolithic component maintaining all possible attributes. Many attributes must be represented in multiple ways. Different ACS systems radically differ with respect to parts, so there is no single, generic compositional model. New attributes reflecting new sensor capabilities, guidance modes, or effectors may need to be added across successive versions of the system. And small, localized components are simpler to Configure in accord with the special physical, resource, and performance demands of any particular instance of an ACS.
Decentralize models. While they may possess aggregate conceptual interfaces, each kind of ACS model should be implemented as a loosely connected bundle of submodels, each responsible for maintaining a small independent set of attributes representing related, physically meaningful abstractions.
The resulting collection of attributes and operations for each kind of model or submodel describes a set of interfaces that may be implemented in many ways. Many kinds of models will share many aspects of common interfaces, which can be factored via interface inheritance to arrive at more compact and useful designs.
However, the following steps do not themselves generate interfaces, only sets of attributes, connections, operations, and protocols that must be arranged into common interfaces according to roles and usage. In fact, because ACS model interfaces are uncomfortably sensitive to policies surrounding control Flow, Monitoring, and Configuration, it is a good idea to design attribute structure early, but to return to operation interfaces only after considering these issues.
These steps and concerns are applied in different ways across the different kinds of models found in an ACS: Navigation Models, Objective Models, Error Models, Action Models, and Intermediate Models.