Proposed CCSDS Architecture Principles 15 June 2006 Peter Shames, NASA/JPL

Proposed CCSDS Proposed CCSDS Architecture PrinciplesArchitecture Principles

15 June 2006

Peter Shames, NASA/JPL

17 June 2006 System Engineering Area PS 2

Agenda

• What is the motivation?– CCSDS Operating Plan, A02.1-Y-2, April 2004 (see also

A00x0Y9 CCSDS Procedures Manual)– 1.5.3.1 CESG Chair Responsibilities

• d) ensuring that all CCSDS work follows an agreed set of architectural principles and is properly synchronized with the smooth evolution of the large installed base of

– 1.5.3.2 Area Director Responsibilities• j) ensuring that all Area work follows the set of architectural

principles agreed by the CESG and is properly synchronized with the smooth evolution of the large installed base of CCSDS-compatible mission support infrastructure;

• No such architectural principles exist as yet• This presentation proposes a set that are derived and

adapted based on a search of relevant literature


Literature Searched

• CCSDS Procedures Manual, A00x0Y9 & CCSDS Operating Plan, A02.1-Y-2, April 2004

• Architectural Principles of the Internet, RFC1958, Carpenter et al• The Open Group Architecture Framework (TOGAF),

v8.1, 2004• CMU Software Engineering Institute (SEI) SW Architecture

Documentation Practice, CMU/SEI-2000-SR-004, 2000• Architecture Definition, Bredemeyer Consulting,

2002• JPL DSMS Information System Architecture (DISA)

Governance Document, v0.7, draft, Mar 2006• Australian Government Enterprise Architecture

Principles, Feb 2003• CORE Architecture Definition Guide, 5.1• Principles of System Architecture, PBWiki


TOGAF Criteria that distinguish a good set of

principles • Understandable: The underlying tenets can be quickly grasped and

understood by individuals throughout the organization. The intention of the principle is clear and unambiguous, so that violations, whether intentional or not, are minimized.

• Robust: Enable good quality decisions about architectures and plans to be made, and enforceable policies and standards to be created. Each principle should be sufficiently definitive and precise to support consistent decision making in complex, potentially controversial, situations.

• Complete: Every potentially important principle governing the management of information and technology for the organization is defined. The principles cover every situation perceived.

• Consistent: Strict adherence to one principle may require a loose interpretation of another principle. The set of principles must be expressed in a way that allows a balance of interpretations. Principles should not be contradictory to the point where adhering to one principle would violate the spirit of another. Every word in a principle statement should be carefully chosen to allow consistent yet flexible interpretation.

• Stable: Principles should be enduring, yet able to accommodate changes. An amendment process should be established for adding, removing, or altering principles after they are ratified initially.


SEI SW Architecture Documentation Practice

1. Documentation should be written from the point of view of the reader, not the writer.

2. Avoid repetition3. Avoid unintentional ambiguity. 4. Use a standard organization.5. Record rationale. 6. Keep it current. 7. Review documentation for fitness of

purpose.


TOGAFRecommended Format for Defining

PrinciplesName Should represent the essence of the rule and be easy to remember. Avoid

ambiguous words in the Name and in the Statement such as: “support,” “open,” “consider,” and “manage(ment)”, and look for unnecessary adjectives and adverbs (fluff).

Statement Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for architecure are similar from one organization to the next. It is vital that the principles statement be unambiguous.

Rationale Should highlight the business benefits of adhering to the principle, using business terminology. Point to the relationships to the principles governing business operations. Describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.

Implications Should highlight the requirements for carrying out the principle - in terms of resources, costs and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed.


Proposed CCSDS Architecture Principles

Organizational1. Primacy of Principles2. Maximize Benefit to the Entire Enterprise, CCSDS and Member Agencies3. Minimize Disruptions to Existing Standards & Installed Systems

Drivers4. Interoperability is Essential and Must Be Demonstrated5. Provide Cross Support Capabilities 6. Deal with Inevitability of Heterogeneity and Change7. Define Standards Independent of Specific Technology, Agency or Vendor8. Design in Robustness in the Face of Disconnection and Disruption

Approach9. Do Architecture First10. Define Interfaces at Natural Boundaries11. Adopt Modularity and Loose Coupling, Reduce Integration Complexity12. Base Leading Standards upon Past Experience & Multi-mission Requirements13. Prefer Unpatented, Internationally Available, Free Technology14. KISS (Keep It Simple, Stupid)

Other Considerations• Do Early Standards Validation and Defect Elimination• Develop Common Vocabulary and Data Definitions• Ensure Scalability Across Different Deployments• Adopt Common Use Applications & Support Re-use


Arch Principles in Detail1. Primacy of Principles

Statement: These architecture principles of apply to all organizations and activities within CCSDS.

Rationale: The only way we can provide a consistent and measurable level of standards development and validation is if all organizations abide by the principles.

2. Maximize Benefit to the Entire Enterprise, CCSDS and Member AgenciesStatement: Decisions are made to provide maximum benefit to the

Enterprise as a whole, the CCSDS organization and its member agencies.

Rationale: This principle embodies "Service above self." Decisions made from a CCSDS-wide perspective have greater long-term value than decisions made from any particular organizational perspective.

3. Minimize Disruptions to Existing Standards & Installed SystemsStatement: Developed standards should be selected so as to add new

capabilities but should minimize disruptions to existing expensive infrastructure investments.

Rationale: As agency systems and commercial capabilities that implement standards become more pervasive, we become more dependent on them and must consider the stability and reliability of such systems throughout their design, development and use. The deployed systems must be capable of supporting current missions even as they are upgraded with new capabilities. Unintended effects on infrastructure and operations due to standards changes will be minimized.


Arch Principles in Detail, cont

4. Interoperability is Essential and Must Be DemonstratedStatement: First and foremost, standards, protocols, and

interfaces should be implemented to promote interoperability for missions, ground assets, services, data, and applications. There shall be two independent implementations that demonstrate interoperability.

Rationale: Standards help ensure interoperability and consistency of implementations, thus improving the ability to integrate, operate, and manage systems and improve user satisfaction. Standards for interoperability additionally help ensure cross support, support from multiple vendors for their products, and facilitate supply chain integration. And perhaps most important: Nothing gets standardized until there are multiple instances of running code.

5. Provide Cross Support CapabilitiesStatement: Standards and protocols developed by CCSDS must

provide capabilities that permit cross support operations and activities between elements owned by different space agencies.

Rationale: All space assets, flight and ground, are expensive to design, develop and operate. Common standards, protcols, and services aid integration and cross support among agencies. Cross support use of services and infrastructure, where this is effective and meets requirements, is more efficient use of CCSDS and agency resources.



6. Deal with Inevitability of Heterogeneity and ChangeStatement: Systems should support a diverse and evolving environment of

missions, agency infrastructure and operations. Multiple types of mission hardware, link capabilities, operational concepts will be in use at the same time and evolving. Multiple types of standards and protocols must be allowed for, ranging from the simplest, such as direct links, up to the most complex such as distributed networks.

Rationale: Hardware changes. Software changes. Mission requirements change. Operational concepts change. Given the lifespan of systems, the variety of technologies, and the variety of systems and missions being developed, it is important that our standards be able to handle the diversity in the environment.

7. Define Standards Independent of Specific Technology, Agency or VendorStatement: Standards and protocols are independent of specific

technology choices, agency local approaches, or vendor products and therefore can be freely adopted and operate on a variety of technology platforms.

Rationale: Independence of applications from choices in underlying technology or implementation approaches allows standards to be developed, upgraded, and operated in the most cost-effective and timely way. Realizing that every decision made respect to standards makes us dependent on that technology, the intent of this principle is to ensure that standards are not dependent on specific hardware and operating systems software.



8. Design in Robustness in the Face of Disconnection and DisruptionStatement: Space data systems that support mission operations

activities must be robust, responsive and reliable, with appropriate redundancy to protect against failure. Standards and interfaces must support development of systems with these characteristics. This will ensure that expected operational service levels can be maintained, especially during times of crisis.

Rationale: Space data systems standards must support a wide variety of agencies, operations concepts, and mission types. Because these space assets are expensive, represent significant long term investments, and in some cases are used to support human missions where safety is critical, they must be robust in the face of a variety of issues. These include, at a minimum, difficult communications environments, noise, disconnection, and disruption.

9. Do Architecture FirstStatement: Architecture is the highest level of design for a given

system. It is the framework and control over all other more-specialized designs in the system. An architectural understanding of what is to be done must precede detailed design of standards.

Rationale: Architecture must have more authority and power than the narrower disciplines. Architecture needs to be settled before serious engineering design can proceed. Architecture is the same discipline as design, but provides an overall vision, controls a higher level of the system, and consequently has different abstractions of information to handle.



10. Define Interfaces at Natural BoundariesStatement: Systems should be separated at natural domain solution

boundaries and integration between these system elements should be loosely coupled.

Rationale: Most design decisions have some long-standing basis in things like practice and culture. In space data systems, certain processing and information entities belong to related solution domains. As an example, it is common practice that the entity “antenna” belongs to “tracking network” even though developing “antennas” is allocated to projects in “engineering”. It is important that designers think through which natural boundaries exist within and among their process structures and interactions and map their system interfaces appropriately.

11. Adopt Modularity and Loose Coupling, Reduce Integration ComplexityStatement: Modularization of the system allows many benefits: loose

coupling, reduction of integration complexity, easier testing, easier accommodation of new capabilities at the component level, and easier accommodation of new components at the system level.

Rationale: Modularity has proven to be a key factor in providing reuse and encapsulating complexity. The Open System Interconnection (OSI) model has proven to be extremely successful to depict layering of communications among computers from different vendors. The OSI, developed International Organization for Standardization (ISO), [http://www.iso.org] addressed very difficult problems of different data formats and data exchange protocols. Other approaches, such as service oriented architectures, are now needed to define open, loosely coupled, systems and interfaces.



12. Base Leading Standards Upon Past Experience & Multi-mission RequirementsStatement: Standards must be developed in advance of

specific mission needs in order to be available when they are required. Leading standards are developed based upon lessons learned from prior missions and analysis of future multi-mission needs.

Rationale: If standards are not developed prior to the design of specific missions they will not be available for mission use. New standards may be identified based upon problems or limitations identified in earlier missions, This concept of leading standards also requires an analysis of aggregate mission needs well in advance of specific mission developments. This principle will foster an atmosphere where the standards and operations environment changes in response to the overall needs of CCSDS and the agencies. Note that changes in standards may provide an opportunity to improve the operational processes and hence, change agency needs.


Arch Principles, in Detail, cont

13. Prefer Unpatented, Internationally Available, Free TechnologyStatement: Unpatented technology that is freely

available to all international partners is preferred, but if the best technology is patented and is available to all at reasonable terms, then incorporation of patented technology is acceptable.

Rationale: The existence of export controls on some aspects of applicable standards is only of secondary importance in choosing which technology to adopt into the standards. All of the technology required to implement CCSDS standards can be fabricated in any country, so world wide deployment of the standards does not depend on its exportability from any particular country or countries



14. KISS (Keep It Simple, Stupid)Statement: All developed standards should strive to

adhere to the KISS principle, "Keep It Simple, Stupid." The architecture of standards and systems should be as simple as possible without conflicting with other design principles. This principle is also known as Occam's Razor.

Rationale: Space data systems standards that are more complex than necessary will result in sub-optimal systems and resources in space are typically very limited, so designs must be kept simple. If there are several ways of doing the same thing, choose one. If one single approach cannot be agreed, settle on a baseline and options or a small set of options.



15. Do Early Standards Validation and Defect EliminationStatement: Standards must be validated thoroughly before they are

released. Defects should be identified and eliminated as early as possible in the standards development process. Perhaps most important: Nothing gets standardized until there are multiple instances of running code that have demonstrated interoperability.

Rationale: The later you are in the process, the more expensive and/or difficult it is to fix defects appropriately. Defect elimination should be an on-going part of the standards development process. Validation of developed standards is an essential part of the process. This normally will involve development of at least two independent implementations that can be tested for full interoperability. This will usually involve an extensive program of testing of design functionality.

16. Develop Common Vocabulary and Data DefinitionsStatement: Syntax and semantics of information is defined consistently

throughout the CCSDS standards, and the definitions are understandable and available to all users.

Rationale: The syntax and semantics of data and terminology that will be used in the development of standards must have a common definition throughout the CCSDS to enable sharing of data. A common vocabulary will facilitate communications and enable dialogue to be effective. In addition, it is required to interface systems and exchange data.


Arch Principles, in Detail, cont

17. Ensure Scalability Across Different Mission Sets & DeploymentsStatement: Systems should be scaleable to support use by

different size organizations and to handle growth or decline in mission complement.

Rationale: Too often, systems elements are designed in such a way as to be difficult to expand significantly, or have such high fixed costs for an implementation that they cannot be implemented for smaller purposes. Our architectures, standards, interfaces, and even deployments must take into account the need for systems to be able to be expanded or contracted as necessary.

18. Adopt Common Use Applications & Support Re-useStatement: Development of common standards and protocols that

may be used across the suite of services is preferred over the development of similar or duplicative services that are only useful to a particular organization or WG.

Rationale: Duplicative capability is expensive to design, develop and validate and proliferates conflicting interfaces that may be difficult to integrate. Development and reuse of standard common use capabilities, where this is effective and meets requirements, is more efficient use of CCSDS and agency resources.


Arch Principles - Other Options

• Only address architectural decisions at high priority leverage points – Strategic objectives– Important distinct services– Systemic or broad impact qualities or properties

• Holistic Thinking– Think holistically about the system, its components, its

usage contexts, and other relevant systems.• All Design Processes Should Involve Iteration • It may be better to adopt an almost complete solution now,

rather than to wait until a perfect solution can be found• Performance and cost must be considered as well as

functionality• Be strict when sending and tolerant when receiving

– Implementations must follow specifications precisely when sending to a peer, and tolerate faulty input from the peer.

• Avoid any design that requires addresses/numbers to be hard coded – User applications should use names rather than addresses.– A single naming structure should be used.

• Compliance with Applicable Laws


Further Considerations

• Define Architecture Principles as a formal document

• Require CESG Architecture Principles review for any new standards– Define a governance process – Architecture Principles checklist


Architecture and Architecting

• Architecture - The concepts and rules that define the structure, semantics, behavior, and relationships among the parts of a system, a plan of something to be constructed. It includes the elements (entities) that comprise the thing, the relationships among the elements, the constraints that affect those relationships, a focus on the parts of the thing, and a focus on the thing as a whole.

• Architecting - The process of defining, documenting, maintaining, improving, and certifying proper implementation of an architecture. It is both a science and an art.

From: RASDS, CCSDS 311x0-M-1

Documents

Proposed CCSDS Architecture Principles 15 June 2006 Peter Shames, NASA/JPL