Today’s satellites support a wide range of civilian and military applications, including televisions, cell phones and Global Position Systems (GPS). As demand for these applications increases, the satellite industry must continue to innovate to provide faster, more efficient, and more cost-effective service. Instead of deploying large, complex geosynchronous satellites, the industry is moving to constellations of smaller satellites flying in formation. These smaller satellites provide the same functionality as their bigger predecessors, but are less expensive to build and launch.

Challenge
While the cost of manufacture and launch scales down with satellite size, the engineering development cost for satellites does not — engineering development cost is mainly driven by the new technology incorporated into the satellite and operational complexity. For example, formation flying will require satellites to possess new technology to communicate with one another as well as complex algorithms to position themselves relative to each other in real time. To meet these new functional requirements, engineers need to explore a wider range of design alternatives, which further drives up development cost.

Increased engineering costs are not the only challenge associated with formation flying, particularly for systems developed using a traditional development process. In such a process, requirement, design, implementation, and test tasks are performed in different tool environments, with many manual and duplicated steps. Textual requirements, captured in tools such as Microsoft Word or IBM Rational DOORS, can be difficult to analyze. For instance, it is difficult to spot inconsistencies between different subsystem requirements when there are thousands of such requirements. Furthermore, designs completed using domain-specific tools cannot be tested at the system level until after they are implemented in software or hardware. In the coding phase, software engineers manually translate code from design documents produced by the algorithm engineers, which can be a time consuming and error-prone process. The test phase is the catch-all for all the defects that accumulate and flow through the previous phases (see Figure 1). As a result, the test phase often constitutes the bulk of development time and cost. The lack of a common tool environment, reliance on manual steps, and inability to discover defects until the latest stages of the project drive up the total time and cost of development.

The already difficult challenges inherent in designing formation flying systems are compounded by addition obstacles imposed by traditional development methods. Engineers need tools that enable them to efficiently explore design alternatives for formation flying systems, reuse existing designs, incorporate new technologies, and optimize system-level performance.

Solution
Model-Based Design starts with the same set of requirements as a traditional process. However, instead of being manually translated into textual specifications, these requirements are used to develop an executable specification in the form of models. By simulating the executable specification, engineers can identify and fix inconsistent or vague requirements early in development. In the design phase, executable specifications serve as a foundation from which algorithm designers elaborate their designs. As the complete design is created in a single modeling environment, subsystem designs spanning multiple domains can be integrated, optimized, and function tested before implementation. Once the design is finalized, the models are used to automatically generate production code and test cases. Finally, engineers can reuse the models to validate software and hardware test results.

With Model-Based Design, engineers stay in the model environment from requirements to test, minimizing manual work and translation errors (see Figure 2). Testing begins at the requirement phase instead of the test phase, shifting defect discovery and elimination earlier in the development process. By enabling engineers to work in the same tool environment, reduce of the number of manual tasks, and find defects earlier, Model-Based Design reduces the total cost of development.

SSC: A Case Study
Engineers working on SSC’s Prisma project, a civil mission, used Model-Based Design to develop two satellites, Mango and Tango, which are capable of autonomous formation flying, autonomous rendezvous, and proximity operations. As part of the project, SSC engineers developed new Guidance, Navigation, and Control (GNC) algorithms for formation flying that took advantage of advanced sensors and propulsion systems. Typically, integrating new algorithms and components would increase the time needed for development.

European Space Agency(ESA) project named Small Missions for Advanced Research and Technology (SMART-1). SSC developed the attitude and orbit control system (AOCS) of SMART-1 using MATLAB and Simulink. Building on their experience using Model-Based Design, SSC engineers reused the models and flight code from SMART-1, made changes to accommodate the new sensors and actuators, and met new mission requirements.

For Mango and Tango, SSC engineers used MATLAB, Simulink, and Stateflow to develop the algorithms, run system-level closed-loop simulations in real-time, and generate flight code. Real-time simulations of the plant models with xPC Target enabled the engineers to reuse the models to rehearse for the actual mission flight operations and verify flight command sequences.

Unlike traditional methods in which control engineers capture the algorithm design in text and diagrams before passing the document to software engineers who interpret it and manually write code, Prisma project engineers reused the same set of models from concept to implementation. Starting in the requirement phase, the engineers used models to communicate with teammates at the French and German space agencies, as well as at the Technical University of Denmark. The models provided an unambiguous set of executable specifications, which helped the multinational team to find and address defects early in the requirement and design phase. Using one set of models also eliminated the need for data reentry and conversion between disparate tool environments. To further improve efficiency, SSC engineers reused SMART-1 models to run tests early in the development process and reused those same tests throughout development to ensure consistency and eliminate redundant work.

Using Model-Based Design to develop formation flying systems on the Prisma project enabled SSC engineers to reuse 70 percent of the attitude control models developed for SSC’s SMART-1 satellite, explore design alternatives, rapidly develop designs that incorporated new sensors and actuators, and reduce total development time by 50 percent.