We recognize that the design objects below are very ambitious, even so ambitious that engineers may doubt our ability to meet them! However, MOLTEK engineers focused our efforts on developing the optimal core architecture for the system, rather than striving to create as many "bells and whistles" in the system as possible. MOLTEK created a solid foundation to build upon that provides the desired characteristics for the system - the bells and whistles come later... MOLTEK's AXIOM™!" System fulfills each of these objectives:
MOLTEK engineers focused on developing the optimal core architecture for the system; cost effective, expandable, updateable, efficient, modular, and intuitive.
Separate operational data that is costly to change from the real-time operations environment:
Changing operational data requires extensive revalidation and evaluation of cascading impacts to other operations. To avoid such extensive revalidation and engineering review, it was desirable to architect AXIOM™ such that changes to operational data are only required when operational METHODS are changed, but not when the real-time environment or desired procedure structure/formatting changes.
Support multiple spacecraft with a single set of operational data:
Design and develop the system to be database-driven and to allow an operations engineer to use software-type logic structures (IF logic, subprocedure calls, etc.) to design a single generic procedure (paper and software) to support many different spacecraft.
Develop a system that will grow with technology and will not become obsolete:
Design a system that can be expanded and upgraded by the user, as user requirements change and the satellite industry grows, such that the system does not become obsolete.
Maintain only a single-source for any piece of data:
Support a modular architecture for operational data that allows all data to be referenced by other data, rather than having to include and maintain the same information in more than place.
Make the system modular:
Design the system so that components can be included or not included independently without impacting each other. This architecture allows individual components to be upgraded or even replaced in the future by new components or COTS software as XML technology and tools advance.
Ensure that the system is intuitive:
The system should be usable by operations engineers and should not require the general user to have a software engineering or XML background. This characteristic avoids the enormous costs and schedule penalties associated with having to pay a separate software engineering group to implement changes that only the operations engineers understand.