- Email: [email protected]
Design of Realtime Onboard GNC Systems Using Integrated Design Tools
Copyright © IF AC Automatic Control in Aerospace, Seoul, Korea, 1998
DESIGN OF REALTIME ONBOARD GNC SYSTEMS USING INTEGRATED DESIGN TOOLS. Finn Ankersen
European Space Research and Technology Center P.O.Box 299, 2200 AG Noordwijk, The Netherlands email: [email protected]
Abstract: In classical designs of onboard real time flight control systems, the design and disciplines are split in many steps from concept, to feedback design, building simulators and finally producing inputs for the real time software development. Here will be shown an integrated design approach where those steps in the design are performed with the same family of design tools, producing in the end real time software for the design. This is applied in a full scale prototype development for the Automated Transfer Vehicle (ATV) . Copyright © J998IFAC Keywords: Space vehicles, satellite control, software tools, robust control, attitude control, computer aided control systems design
orbital transfer from a lower orbit into the vicinity of the ISS orbit some kilometers behind the ISS (drift phase), at which point the closed loop control relative to the ISS starts and is followed by a 2-pulse ~ V Homing maneuver to bring the ATV to a distance of about 2.5 [km] followed by another 2-pulse ~ V Closing maneuver. The navigation until now has been based on relative GPS (RGPS). If the approach is along the z-axis then this maneuver is followed by a fly-around which can either be a 2-pulse or a trajectory tracking maneuver.
1. INTRODUCTION Development time and budgets are both becoming smaller for spacecraft developments, which encourages to search for new ways of development methods. This paper deals with the design , development and implementation of real time Guidance, Navigation and Control (GNC) systems using modern commercial integrated design tools contrary to classical and established methods (Isi, 1995). This method has been applied to a full scale prototype development for the ATV. The phase of the ATV mission considered here is the Rendez-Vous and Docking (RVD) phase with the International Space Station (ISS), which is the most complex and demanding part of the mission.
The Final approach navigation is based on an optical sensor system from a distance of about 250 [m], either along the x-axis or the z-axis. Below 40 [m] distance, both relative position, attitude and their rates are closed loop controlled, otherwise only relative position and velocity are. Beyond the modes mentioned here there are also modes for emergency stop, collision avoidance, departure etc.
2. MISSION DESCRIPTION The mission consists of launch, orbit injection, phasing to get closer to the ISS, orbital transfer to get on almost the orbit of the ISS, the RVD phase, departure and finally deorbiting. We will concentrate on the RVD phase which is illustrated in Fig. 1.
3. SYSTEM DESCRIPTION
The RVD part is broken down into phases as seen in Fig. 1. It starts with a Hohmann type of
The functionality of the onboard system is shown in Fig. 2 The Data Management System (DMS) , the general onboard services, the main part of the telemetry handling and the operational aspects will not be considered further here.
1 This work has been supported by the work and results obtained under contract (ATV, 1994) .
353
Mission Scenario Orbit
Final approach Velocity vector
/7.2krn ________-=25~krn~
ISS
X~!C=====1==~-:~tt==~--------~------~--
ATV
Fly-around
Homing Drift Phase
z Fig. 1. Phases of the RVD part of the mission. x and z-axes are in the orbital plane. ATV. The state vector x = [x,y,z,x,y,zy. This only concerns the translational motion. Position and attitude motions are treated decoupled until the relative distance is smaller than about 40 [m]. The attitude can be described by the standard Euler equations, and for the state vector is considered 0 = [0x0y0zexeyez], in its linear form.
Both the ATV and the ISS receives signals from the G PS for absolute navigation. In order to perform RG PS navigation it is necessary that the ISS communicate its GPS data to the ATV. The optical sensor looks from the d0cking port on the ATV and sees a target pattern mounted next to the docking port of the ISS, and eventually at the end of the final approach .the two docking ports will get contact and become latched together.
The couplings between the translation and the rotation is of a geometrical nature due to the fact that torques are generated by means of forces and a lever arm to the center of mass (COM) as well as the docking ports are not situated at the COM but several meters away. The coupled system can be represented by
4. GNC SYSTEM DESCRIPTION Before providing a more detailed description of the GNC system a model of the relative dynamics between the two spacecraft will be provided.
x(t) = f(t, 0(t), F(t), N(t), d(t))
Let us define a target coordinate system as follows, in which the dynamics equations will be valid, see Fig. 1:
0(t)
In Fig. 3 is illustrated the principal GNC feedback loop. The main individual blocks will now be described in terms of their type and complexity, but not the detailed design.
The state space equations for the relative dynamics are the Clohessy-Wiltshire equations as follows
x = Ax+Bu x=
[0oo o o o
0
1 0 0] x+
(3)
where F(t) and N(t) is the control force and torque acting on ATV respectively and d(t) is the disturbances. ( 2) and ( 3) can be combined into one description of 12th order.
• x-axis: Tangential to and in the orbit plane in the direction of the velocity vector. • y-axis: Normal to the orbit plane and pointing to the southern hemisphere. • z-axis: Radial to the orbit and pointing towards the Earth center.
0 0 0 010 0 0 001 o 0 2w 0 0 _w2 0 000 0 3w 2 -2w 0 0
= g(t, F(t), N(t), d(t))
(2)
4.1 Control Function
[000] 000 000 1 00 010 0 0 1
The controller is designed by using the design facilities in (Isi, 1995). The controller is of MIMO structure, of Hoo type and the Normalized Coprime Factorization has been used for the design to obtain the required robustness.
u -- (1) me
where the output equals the vector x and:
The robust stability of the complete system has been assessed by means of the J.L-analysis where real valued uncertainties can be represented (Math Works, 1996).
u~ [~l
Position and attitude controllers are separate above 40 [m]. Below that distance the plant described by ( 2) and ( 3) is controlled by one high
where w is the orbital rate of the ISS, me is the ATV mass and F; are the forces acting on the 354
System Description __
~~~~~ ~SrS~atuel~li~te~s~~__________________________________~
/
\
~ ~
Docking
bus
. Pons
Target pattern
!
~
GPSData
lMnC
Fig. 2. Functionality of the onboard system blocks. order controller, where cross couplings are taken into account in the design. The state variables are transformed into a fictitious coordinate system, attached at an arbitrary but convenient point, in order to have a convenient representation with the minimum number of couplings.
5. ONBOARD SYSTEM The onboard system, is illustrated in Fig. 2 and Fig. 4. Beyond the GNC components described in section 4, there is also the mission and vehicle management (MVM), which is hierarchically one level higher. The MVM is in charge of all the mode management and sequencing, together with activating or deactivating the equipment needed for the different modes. This is performed in a combination of nominal sequence and event driven mode change, e.g. a change to an emergency stop initiated automatically or upon request.
4.2 Navigation Function The estimation filters are less complex due to the fact that they are kept as SISO filters of 2nd order nature, except for the final approach with relative attitude estimation, where the filters have a MIMO structure. The filters are grouped according to the G PS or optical sensor based phases.
Beyond those described so far, there are other general and common functionalities onboard, which will not dealt further with here.
For the GPS based phase a time variant Kalman filter has been implemented, which involves solving the covariance and Ricatti equations online, which is an implementational complication.
6. CLASSICAL DEVELOPMENT STRATEGY The classical development approach is shown in Fig. 5. After the concept definition is finished, all the modes are defined and can be placed together as the first step to define the architecture. Then comes the design of the various algorithms for filters, failure detection etc. This can either be a new design or it can be reuse and it means that all the dynamic filters etc. will have to be implemented in some control systems design tool, where the tuning will take place as well as some simulation, stability and robustness analysis. After this the tuned algorithms will have to be coded and executed in a simulation verification environment together with the failure detection, which interacts with the GNC blocks, and the on-board management system, MVM. Now there is an iterative process between this verification environment and the implementation in the design tools. As long as modifications concern established structures, the work is not too large in the manual transfer of gains etc., but if the structure becomes different it is a matter of recoding the algorithm again, in
For the optical sensor phase the filter is a fixed gain filter of state observer type and for the relative attitude part it is a MIMO type filter taking the coupling in the system into account.
4.3 Guidance Function The guidance function computes the reference trajectories for all the phases, as well as it is in charge of providing a smooth trajectory for the switch from G PS based to optical based navigation. This is necessary as the 2 navigation domains have quite different accuracies and would otherwise be followed by too large transients. In addition to this the guidance function also calculates the necessary feedforward control, typically for the pulsed maneuvers, where the pulses are effectuated as feedforward and the feedback control shall keep the output close to the trajectory associated with the pulses. 355
1 Guidance .
,,
f-:O + .
Comrol
1-:
I
.1
I--"'-X
Plan! Actuation t - Translation Rotation
H in1r-:
~
I-....,-f-Theta
I I
Inertia]
,
:
--- - ----- - -- - -- - ------
~]
Navigation (RVS, RGPS) -:
1-----1
Measure.,.. Urut
.
Opucal Sensor
Mimn
I--
.............•........................... . .................................... .... ............... ..
Fig. 3. The principal GNC feedback loop. addition to the associated interface changes. It is to be noted that experience shows that about 60% of discovered errors are introduced at this level, and the larger part of these will not be discovered until the next step (Ellenberger, 1997; Isi-a, 1997).
as important in terms of time saving. The design approach is illustrated in Fig. 6. There are two main differences wrt. section 6; one is that the design and simulation environment to a very large extent will be combined in the same commercial tool and the second is the concept of machine generated code for a larger part of the on-board flight software. .
The final step in terms of coding is to generate the flight code. This is typically done according to a software engineering standard; in this case according to (ESA, 1994). This means that parts of the algorithms etc. will have to be coded again. It is to be noted that all these levels of repeated coding of the same algorithms is a manual task with a potential of introducing additional errors at each operation. The flight software then has to be tested in real time. This means that the present non-real time simulator, for performance evaluation, cannot be used, but yet another simulator will have to be used for that purpose. Errors that are discovered at this level are usually very costly to correct as it is necessary to return back to the design level, 3 steps upward in Fig. 5, and then proceed again with another iteration. The turn around time for such iterations are often in the order of half to whole days before a new flight software is validated, in particular in larger projects involving several industries. This does not take into account the cost of changing the associated documentation.
The high level requirements, such as: operating modes, command and data handling specifications and general systems behavior can be modeled using blocks and state diagrams from an extensive library of predefined modules. Since the specifications are in a graphical language, data entry is very rapid, and specification changes can be easily understood by developers of other subsystem models. This can help to increase communication between different development teams. See also top part of Fig. 6. Functions not available in libraries can easily be linked by means of convenient user code blocks. A system level model can then be automatically generated from the modeling and simulation tool. By automating the detailed design process, less time will be spent debugging the implementation
In summary it follows the way from the system/software requirements stage mixture with software requirements analysis, preliminary design, detailed design, coding and unit testing, subsystem integration, testing, system testing and verification.
Systemslw,-_ _ _ _ _ _ _ _ _ _ _ _ _---, 1 Sub!}'Stem sIw I Subsystem sIw RendezVous Control Software MVM
I
Guidance
I
Navigatioo
Control
-
7. THE INTEGRATED DESIGN APPROACH Services
Today there are commercial tools available which can be very useful and cost beneficial for the type of development considered here. Not only is it beneficial in terms of reduced manual work, but many error sources will be eliminated, which is
Fig. 4. The blocks of the onboard system for the RVD phase.
356
and more time can be spent understanding system concepts and design requirements.
Design a.ll
mode~
t
The graphical block diagram implementation will precisely capture subsystem data and command interface specifications, their functional behavior and timing requirements. The built in hierarchy allow for arbitrary complex systems to be designed simply using layers of growing complexity in terms of nested systems of blocks. This breakdown with all specified interfaces and labeled interconnections can be obtained graphically, which is very important for consistent documentation as well.
I I
Take algorithms from previous development
1 Design new algorithms where needed.
• Code all ..lgorithms, MVM etc.
t For tuning a.nd testing ~
implement all GNC in &
control design tool.
Extract tuned gains etc.
The actual GNC design is performed on the various subsystems specified without having to implement anything in addition to what is already present. This is still an iterative process, as illustrated in Fig. 6, but the simulation and verification is performed without leaving this design environment, which eventually means without yet generating any software code. Specification and design errors can then be caught in these initial simulations.
a.nd manually reimple.
Implement ney in design tool.
I-- algorithms
mplement in
~
imulator env.
ment performance simu-
la.ter environment.
no..:j
+
..:0
Transfer to flight s/w
Implement in
aga.in and test perf.
flight software
no"j
t
The final detailed design is now finalized and an automatic generation of software can be performed in order to obtain the on-board flight software. The code generator will then be able to automatically generate real-time Ada or C source code directly from the same block diagrams. The code generator provides templates to facilitate customization of the generated code to meet style and structure requirements. This means that specification changes later in a project can be afforded with minimal risk to the project schedule.
go
Loa.d flight software
on target ha.rdware a.nd make final tests.
no"j
+go
Fig. 5. Classical cycles for the development of onboard GNC systems from the design phase until the validated flight software. modeling and simulation tool. The implementation consists of:
The real-time hardware in the loop system tests can now be performed with a system that integrates with the design tool and which is compatible with the environment of the chosen processor, or it can be ported to another test bench. Choosing the latter means additional costs and risk as the test environment is now different, with the problems that it usually brings along. The real time scheduler can either be generated automatically or it can be chosen to use the one of the embedded operating system.
• 12 different main phases during RVD, which are implemented by means of state transition diagrams. Below those there are several other state diagrams to control the logic of equipment, filters etc. • 282 so called SuperBlocks, with 5-10 other blocks embedded in each one of them, have been implemented for the system. • The models of the space environment like GPS constellation, gravity fields, atmosphere etc. are not suited for direct implementation in the modeling and simulation tool, but are coded in the C-Ianguage, and then hooked up to the rest via a hook in the graphical implementation to the external software. • Models of sensors and actuators are implemented in both environments; directly and by means of external code. This is driven partly by ease of implementation and partly by reuse of past models. • The telemetry coding and decoding is also implemented in software due to its nature.
8. RESULTS OF THE INTEGRATED APPROACH The RendezVous control system described has been designed by means of the MatrixJM family of tools and fully implemented therein. The implementation is done in the modeling and simulation tool, script files associated to it and software written in the C-Ianguage for the simulation of the space environment and for functions which are not suitable to be implemented directly in the
What has been described so far, all runs completely integrated in the tool. It is first being 357
used as the design iteration simulator, and as it contains all the high fidelity models and the real onboard algorithms, it is later being used for the detailed performance simulations and verification as well. It is also the reference of a correct functioning system for the later autocoded flight software, as all the reference data used for that purpose, will be gen~rated here.
Implement the MVM, PMM etc. in state transition diagrams with a CAE tool.
.1 Implement all the GNC (old/new) in System Build for design and simulation.
" -.1
The next step is to generate automatically the on board software, which is generated from the onboard part of the implementation. In that connection the following shall be addressed:
Implement in external user code part of environmental models. (much can be reused from earlier) .
1
• The interface software to the onboard software, which is not automatically generated must be defined , written and be ready for use. • The style of the automatically generated software shall be ensured by customizing the templates accordingly, which determines how the software will be structured and appear. • The real time scheduler of the operating system will be used and therefore there is not a need for the automatically generated one. Nevertheless it will be generated, and discarded, as this ensures to have complete data consistency between all the blocks and modules. Otherwise this would have had to be done manually, and the whole approach falls to the ground, if one only autocoded in a procedural manner.
,.
Carry out the design of the GNC for performance and stability test etc.
nogo go Generate via Autocode a new version of the flight software and combine with nonauto generated code.
.J. Simulation code adaptation to specific needs for cpmpiler, architecture etc.
~ Download to flight hardware and perform real time performance tests.
On a Sun SparcStation under Solaris 2.5.1 and using the Sun SparcCompiler C version 3.0.1 with the -x02 option the total software size is about 1150 kB, with roughly 950 kB of generated code. User code blocks account for about 60 kB, data definitions for about 60 kB and TMjTC, IjF and scheduling for about 80 kB. Using the -fast option significantly reduces both the size and the execution time, but this compiler option is fragile.
nogo go
Fig. 6. Integrated development of on-board GNC systems from the design phase until the validated flight software. puter and running is about 0.5 hour, including reference data generation, verification and documentation update. This is the point where the method really show its full power.
A better compiler will be able to reduce the code size significantly, and combined with higher level data structures about half the size is expected, taking all the points of section 9 into account as well. This size is estimated some 10-20% larger that a manually coded software, but with much less effort. It is clear that a generic code generator cannot be as optimal as manual coding.
9. LESSONS LEARNED
The execution times for the software is to some extend mode dependent, but for all of them it is possible to stay below ~ 60% of the regular GNC cycle, for the ERC32 Sparc processor, which is quite comfortable.
Before going to the detailed technical points, part of this section is a risk assessment of the whole approach, keeping in mind that this is dealing with safety critical software in connection with a manned space station. The risks identified at the beginning of the project are listed below followed by their evaluation toward the end of the project:
About 15-20% of the software is manually written in order to interface properly with the rest of the onboard system. Turn around time from making a modification e.g a critical interface change until the software is down loaded on the target com-
(1) Qualification of the tool: It is important that the user has full confidence that the tool is qualified, either by a larger set of similar users or by insight into the qualification
358
(2)
(3)
(4)
(5)
(6)
(7)
measures taken by the vendor. In the case of the Matrix~M family of tools there has been reluctance to provide such insight by the vendor. Resources needed by the final system: As the architecture is defined via the system structure laid out in the modeling and simulation tool it is more difficult for the software people to get an idea of the CPU, memory and real time demands; at least seen by someone with a classical development background. It must nevertheless be kept in mind that this will most likely be compensated by the possibility to generate parts of the real code automatically, extremely early in a project, so estimates are not needed in the same manner as before. Bugs in the tool: There are always some bugs in tools, compilers etc., so this is not much different from the classical approach. Bugs were found. Some were easily corrected, some were more difficult. A known bugs list from the vendor would have been very useful, but was unfortunately rejected. One advantage is that the bugs are consistent, which cannot be said in manual programming with many persons involved. Debugging software via graphics : As manual intervention in the generated software is strictly prohibited, identified problems cannot be solved in the classical manner. It will have to be solved either via the code generator templates or via the implementation, which is still not always a straight forward and established way. Configuration management: This is certainly needed for both the software and the implementation. It was not possible with the tool release used in (ATV, 1994), but in the latest release together with another product it is possible and strictly necessary when a multi industrial development is present. Design rules: As the software architecture is driven by the implementation in the modeling and simulation tool, the software people will have to provide to the control systems design people a set of design or implementation rules to follow. Problems can arise if those are not followed, but this is also the case for manual coding, just at a different place in the development process. Monitoring of software performance: It is now more difficult to measure the performance seen from a contractual point of view, as the software and GNC design is somewhat merged. This calls for different ways of allocating wrt. responsibilities.
development in full scale has been quite successful. From that process, a table of recommendations and recording of problem areas will follow: • It is mandatory to issue design and implementation guidelines for the modeling and simulation tool in order to get desired software out. • The modeling and simulation tool can be used very successfully in the beginning to design almost completely the architecture with labels and all interfaces in an electronic forms. Very easy to distribute, use and maintain compared to traditional interface control via documentation. • It is important to evaluate carefully which type of system is suited for implementation in the modeling and simulation tool and what should be implemented directly and what should be attached in external software. Typically time varying Kalman filters are not suited, as there is a lot of matrix algebra and vectors involved in the Ricatti equations. This should conveniently be handled in an external user code block. This problem should nevertheless be releaved in the next tool release as block connections will change from presently scalars only, to vectors. • It is important that GNC designers and software designers work more closely together early in a project and try to obtain understanding of each others fields and constraints. The importance is driven by the fact that the software architecture and other software details are actually partly designed via the implementation in the modeling and simulation tool, which is done by the GNC designers traditionally, and the by fact that the GNC will always have to be designed first, as the software is a medium of implementing the GNC. • For large complex projects it is recommended, at not too late a point, to freeze the release of the design tool and to get an agreement with the vendor that it will be supported during the expected lifetime of the project. Explicit arrangements are needed as only the last 2 releases are on normal support of a vendor to solve problems. • The automatic generation of the real time scheduler is strongly recommended in order to keep data consistency and interfaces clean. When the real time kernel provides a scheduler use that and discard the one autogenerated. If the autogenerated scheduler is used at sublevel it must be ensured it cannot prevent higher level authority. • It is recommended to label properly all connections between blocks and make use of the comment fields to write the module docu-
Beyond this risk assessment it can be said that the whole process and design during this prototype
359
•
•
•
•
mentation fully. This enhances the possibility to generate automatic and useful documentation of the software. It is recommended to use different colors to identify easily different parts of the implementation. It is recommended to build smaller modules, test them, generate the software for them, test it and then proceed to make it more complex. This approach has proven very beneficial. The software standards (ESA, 1994) need some adaptation in order to handle this development approach, as the software life cycle is modified, e.g do the Architectural Design Documents and the Detailed Design Documents no longer exists, but are in the shape of the implementation in the modeling and simulation tool, which can give problems applying the standard directly, as is normally done by requesting the company producing the software. Debugging has shown to be a problem, especially prior to gained experience. As no real debugger exists for the modeling and simulation tool, it can be troublesome to find errors and also are problems at software level not easily traceable back to the implementation. This is still an open area for further investigations.
11. REFERENCES ATV 1994, ATV Rendez Vous Predevelopment. European Space Agency contract. 11 173/94/F /WE Ellenberger R., Ling R., Buscher D., Lacovara J. and Shuler R.,1997. Automatic Generation of Real- Time Ada Simulation for Space Station Freedom. Johnson Space Center, Houston, TX. ESA 1994, Software Engineering Standard PSS05-0 Issue 2. Isi 1995, Xmath, M atrix:z;, Systembuild, Autocode and DocumentIt family of tools. Integrated Systems Inc. Isi-a 1993, Response Times. Vol 6, Issue 1, Integrated Systems Inc. MathWorks 1996, Mat/ab Robust Control Module. Mathworks Inc.
Despite that some of the points above are of negative nature, it has indeed been found beneficial to follow this approach, which in several fields is the trend to future developments. There is always a cost for learning to be paid for the first time, but for experienced tool users there is certainly potential for savings in both cost and schedule of about 50% or more. 10. CONCLUSION The real time onboard GNC system for the ATV spacecraft for the RendezVous and Docking parts have been successfully developed following an integrated tools design approach integrating GNC design, simulation and automatic real time software generation. It has been a full scale development including all facets of a true flight system. The system has been verified with hardware in the loop, fulfills the specifications and it has shown that such a large and complex system is indeed feasible to be developed with such an approach with savings on both cost and schedule; especially after the slope of the learning curve is reduced and savings on cost and schedule of ~ 50% can be expected.
360
DESIGN OF REALTIME ONBOARD GNC SYSTEMS USING INTEGRATED DESIGN TOOLS. Finn Ankersen
European Space Research and Technology Center P.O.Box 299, 2200 AG Noordwijk, The Netherlands email: [email protected]
Abstract: In classical designs of onboard real time flight control systems, the design and disciplines are split in many steps from concept, to feedback design, building simulators and finally producing inputs for the real time software development. Here will be shown an integrated design approach where those steps in the design are performed with the same family of design tools, producing in the end real time software for the design. This is applied in a full scale prototype development for the Automated Transfer Vehicle (ATV) . Copyright © J998IFAC Keywords: Space vehicles, satellite control, software tools, robust control, attitude control, computer aided control systems design
orbital transfer from a lower orbit into the vicinity of the ISS orbit some kilometers behind the ISS (drift phase), at which point the closed loop control relative to the ISS starts and is followed by a 2-pulse ~ V Homing maneuver to bring the ATV to a distance of about 2.5 [km] followed by another 2-pulse ~ V Closing maneuver. The navigation until now has been based on relative GPS (RGPS). If the approach is along the z-axis then this maneuver is followed by a fly-around which can either be a 2-pulse or a trajectory tracking maneuver.
1. INTRODUCTION Development time and budgets are both becoming smaller for spacecraft developments, which encourages to search for new ways of development methods. This paper deals with the design , development and implementation of real time Guidance, Navigation and Control (GNC) systems using modern commercial integrated design tools contrary to classical and established methods (Isi, 1995). This method has been applied to a full scale prototype development for the ATV. The phase of the ATV mission considered here is the Rendez-Vous and Docking (RVD) phase with the International Space Station (ISS), which is the most complex and demanding part of the mission.
The Final approach navigation is based on an optical sensor system from a distance of about 250 [m], either along the x-axis or the z-axis. Below 40 [m] distance, both relative position, attitude and their rates are closed loop controlled, otherwise only relative position and velocity are. Beyond the modes mentioned here there are also modes for emergency stop, collision avoidance, departure etc.
2. MISSION DESCRIPTION The mission consists of launch, orbit injection, phasing to get closer to the ISS, orbital transfer to get on almost the orbit of the ISS, the RVD phase, departure and finally deorbiting. We will concentrate on the RVD phase which is illustrated in Fig. 1.
3. SYSTEM DESCRIPTION
The RVD part is broken down into phases as seen in Fig. 1. It starts with a Hohmann type of
The functionality of the onboard system is shown in Fig. 2 The Data Management System (DMS) , the general onboard services, the main part of the telemetry handling and the operational aspects will not be considered further here.
1 This work has been supported by the work and results obtained under contract (ATV, 1994) .
353
Mission Scenario Orbit
Final approach Velocity vector
/7.2krn ________-=25~krn~
ISS
X~!C=====1==~-:~tt==~--------~------~--
ATV
Fly-around
Homing Drift Phase
z Fig. 1. Phases of the RVD part of the mission. x and z-axes are in the orbital plane. ATV. The state vector x = [x,y,z,x,y,zy. This only concerns the translational motion. Position and attitude motions are treated decoupled until the relative distance is smaller than about 40 [m]. The attitude can be described by the standard Euler equations, and for the state vector is considered 0 = [0x0y0zexeyez], in its linear form.
Both the ATV and the ISS receives signals from the G PS for absolute navigation. In order to perform RG PS navigation it is necessary that the ISS communicate its GPS data to the ATV. The optical sensor looks from the d0cking port on the ATV and sees a target pattern mounted next to the docking port of the ISS, and eventually at the end of the final approach .the two docking ports will get contact and become latched together.
The couplings between the translation and the rotation is of a geometrical nature due to the fact that torques are generated by means of forces and a lever arm to the center of mass (COM) as well as the docking ports are not situated at the COM but several meters away. The coupled system can be represented by
4. GNC SYSTEM DESCRIPTION Before providing a more detailed description of the GNC system a model of the relative dynamics between the two spacecraft will be provided.
x(t) = f(t, 0(t), F(t), N(t), d(t))
Let us define a target coordinate system as follows, in which the dynamics equations will be valid, see Fig. 1:
0(t)
In Fig. 3 is illustrated the principal GNC feedback loop. The main individual blocks will now be described in terms of their type and complexity, but not the detailed design.
The state space equations for the relative dynamics are the Clohessy-Wiltshire equations as follows
x = Ax+Bu x=
[0oo o o o
0
1 0 0] x+
(3)
where F(t) and N(t) is the control force and torque acting on ATV respectively and d(t) is the disturbances. ( 2) and ( 3) can be combined into one description of 12th order.
• x-axis: Tangential to and in the orbit plane in the direction of the velocity vector. • y-axis: Normal to the orbit plane and pointing to the southern hemisphere. • z-axis: Radial to the orbit and pointing towards the Earth center.
0 0 0 010 0 0 001 o 0 2w 0 0 _w2 0 000 0 3w 2 -2w 0 0
= g(t, F(t), N(t), d(t))
(2)
4.1 Control Function
[000] 000 000 1 00 010 0 0 1
The controller is designed by using the design facilities in (Isi, 1995). The controller is of MIMO structure, of Hoo type and the Normalized Coprime Factorization has been used for the design to obtain the required robustness.
u -- (1) me
where the output equals the vector x and:
The robust stability of the complete system has been assessed by means of the J.L-analysis where real valued uncertainties can be represented (Math Works, 1996).
u~ [~l
Position and attitude controllers are separate above 40 [m]. Below that distance the plant described by ( 2) and ( 3) is controlled by one high
where w is the orbital rate of the ISS, me is the ATV mass and F; are the forces acting on the 354
System Description __
~~~~~ ~SrS~atuel~li~te~s~~__________________________________~
/
\
~ ~
Docking
bus
. Pons
Target pattern
!
~
GPSData
lMnC
Fig. 2. Functionality of the onboard system blocks. order controller, where cross couplings are taken into account in the design. The state variables are transformed into a fictitious coordinate system, attached at an arbitrary but convenient point, in order to have a convenient representation with the minimum number of couplings.
5. ONBOARD SYSTEM The onboard system, is illustrated in Fig. 2 and Fig. 4. Beyond the GNC components described in section 4, there is also the mission and vehicle management (MVM), which is hierarchically one level higher. The MVM is in charge of all the mode management and sequencing, together with activating or deactivating the equipment needed for the different modes. This is performed in a combination of nominal sequence and event driven mode change, e.g. a change to an emergency stop initiated automatically or upon request.
4.2 Navigation Function The estimation filters are less complex due to the fact that they are kept as SISO filters of 2nd order nature, except for the final approach with relative attitude estimation, where the filters have a MIMO structure. The filters are grouped according to the G PS or optical sensor based phases.
Beyond those described so far, there are other general and common functionalities onboard, which will not dealt further with here.
For the GPS based phase a time variant Kalman filter has been implemented, which involves solving the covariance and Ricatti equations online, which is an implementational complication.
6. CLASSICAL DEVELOPMENT STRATEGY The classical development approach is shown in Fig. 5. After the concept definition is finished, all the modes are defined and can be placed together as the first step to define the architecture. Then comes the design of the various algorithms for filters, failure detection etc. This can either be a new design or it can be reuse and it means that all the dynamic filters etc. will have to be implemented in some control systems design tool, where the tuning will take place as well as some simulation, stability and robustness analysis. After this the tuned algorithms will have to be coded and executed in a simulation verification environment together with the failure detection, which interacts with the GNC blocks, and the on-board management system, MVM. Now there is an iterative process between this verification environment and the implementation in the design tools. As long as modifications concern established structures, the work is not too large in the manual transfer of gains etc., but if the structure becomes different it is a matter of recoding the algorithm again, in
For the optical sensor phase the filter is a fixed gain filter of state observer type and for the relative attitude part it is a MIMO type filter taking the coupling in the system into account.
4.3 Guidance Function The guidance function computes the reference trajectories for all the phases, as well as it is in charge of providing a smooth trajectory for the switch from G PS based to optical based navigation. This is necessary as the 2 navigation domains have quite different accuracies and would otherwise be followed by too large transients. In addition to this the guidance function also calculates the necessary feedforward control, typically for the pulsed maneuvers, where the pulses are effectuated as feedforward and the feedback control shall keep the output close to the trajectory associated with the pulses. 355
1 Guidance .
,,
f-:O + .
Comrol
1-:
I
.1
I--"'-X
Plan! Actuation t - Translation Rotation
H in1r-:
~
I-....,-f-Theta
I I
Inertia]
,
:
--- - ----- - -- - -- - ------
~]
Navigation (RVS, RGPS) -:
1-----1
Measure.,.. Urut
.
Opucal Sensor
Mimn
I--
.............•........................... . .................................... .... ............... ..
Fig. 3. The principal GNC feedback loop. addition to the associated interface changes. It is to be noted that experience shows that about 60% of discovered errors are introduced at this level, and the larger part of these will not be discovered until the next step (Ellenberger, 1997; Isi-a, 1997).
as important in terms of time saving. The design approach is illustrated in Fig. 6. There are two main differences wrt. section 6; one is that the design and simulation environment to a very large extent will be combined in the same commercial tool and the second is the concept of machine generated code for a larger part of the on-board flight software. .
The final step in terms of coding is to generate the flight code. This is typically done according to a software engineering standard; in this case according to (ESA, 1994). This means that parts of the algorithms etc. will have to be coded again. It is to be noted that all these levels of repeated coding of the same algorithms is a manual task with a potential of introducing additional errors at each operation. The flight software then has to be tested in real time. This means that the present non-real time simulator, for performance evaluation, cannot be used, but yet another simulator will have to be used for that purpose. Errors that are discovered at this level are usually very costly to correct as it is necessary to return back to the design level, 3 steps upward in Fig. 5, and then proceed again with another iteration. The turn around time for such iterations are often in the order of half to whole days before a new flight software is validated, in particular in larger projects involving several industries. This does not take into account the cost of changing the associated documentation.
The high level requirements, such as: operating modes, command and data handling specifications and general systems behavior can be modeled using blocks and state diagrams from an extensive library of predefined modules. Since the specifications are in a graphical language, data entry is very rapid, and specification changes can be easily understood by developers of other subsystem models. This can help to increase communication between different development teams. See also top part of Fig. 6. Functions not available in libraries can easily be linked by means of convenient user code blocks. A system level model can then be automatically generated from the modeling and simulation tool. By automating the detailed design process, less time will be spent debugging the implementation
In summary it follows the way from the system/software requirements stage mixture with software requirements analysis, preliminary design, detailed design, coding and unit testing, subsystem integration, testing, system testing and verification.
Systemslw,-_ _ _ _ _ _ _ _ _ _ _ _ _---, 1 Sub!}'Stem sIw I Subsystem sIw RendezVous Control Software MVM
I
Guidance
I
Navigatioo
Control
-
7. THE INTEGRATED DESIGN APPROACH Services
Today there are commercial tools available which can be very useful and cost beneficial for the type of development considered here. Not only is it beneficial in terms of reduced manual work, but many error sources will be eliminated, which is
Fig. 4. The blocks of the onboard system for the RVD phase.
356
and more time can be spent understanding system concepts and design requirements.
Design a.ll
mode~
t
The graphical block diagram implementation will precisely capture subsystem data and command interface specifications, their functional behavior and timing requirements. The built in hierarchy allow for arbitrary complex systems to be designed simply using layers of growing complexity in terms of nested systems of blocks. This breakdown with all specified interfaces and labeled interconnections can be obtained graphically, which is very important for consistent documentation as well.
I I
Take algorithms from previous development
1 Design new algorithms where needed.
• Code all ..lgorithms, MVM etc.
t For tuning a.nd testing ~
implement all GNC in &
control design tool.
Extract tuned gains etc.
The actual GNC design is performed on the various subsystems specified without having to implement anything in addition to what is already present. This is still an iterative process, as illustrated in Fig. 6, but the simulation and verification is performed without leaving this design environment, which eventually means without yet generating any software code. Specification and design errors can then be caught in these initial simulations.
a.nd manually reimple.
Implement ney in design tool.
I-- algorithms
mplement in
~
imulator env.
ment performance simu-
la.ter environment.
no..:j
+
..:0
Transfer to flight s/w
Implement in
aga.in and test perf.
flight software
no"j
t
The final detailed design is now finalized and an automatic generation of software can be performed in order to obtain the on-board flight software. The code generator will then be able to automatically generate real-time Ada or C source code directly from the same block diagrams. The code generator provides templates to facilitate customization of the generated code to meet style and structure requirements. This means that specification changes later in a project can be afforded with minimal risk to the project schedule.
go
Loa.d flight software
on target ha.rdware a.nd make final tests.
no"j
+go
Fig. 5. Classical cycles for the development of onboard GNC systems from the design phase until the validated flight software. modeling and simulation tool. The implementation consists of:
The real-time hardware in the loop system tests can now be performed with a system that integrates with the design tool and which is compatible with the environment of the chosen processor, or it can be ported to another test bench. Choosing the latter means additional costs and risk as the test environment is now different, with the problems that it usually brings along. The real time scheduler can either be generated automatically or it can be chosen to use the one of the embedded operating system.
• 12 different main phases during RVD, which are implemented by means of state transition diagrams. Below those there are several other state diagrams to control the logic of equipment, filters etc. • 282 so called SuperBlocks, with 5-10 other blocks embedded in each one of them, have been implemented for the system. • The models of the space environment like GPS constellation, gravity fields, atmosphere etc. are not suited for direct implementation in the modeling and simulation tool, but are coded in the C-Ianguage, and then hooked up to the rest via a hook in the graphical implementation to the external software. • Models of sensors and actuators are implemented in both environments; directly and by means of external code. This is driven partly by ease of implementation and partly by reuse of past models. • The telemetry coding and decoding is also implemented in software due to its nature.
8. RESULTS OF THE INTEGRATED APPROACH The RendezVous control system described has been designed by means of the MatrixJM family of tools and fully implemented therein. The implementation is done in the modeling and simulation tool, script files associated to it and software written in the C-Ianguage for the simulation of the space environment and for functions which are not suitable to be implemented directly in the
What has been described so far, all runs completely integrated in the tool. It is first being 357
used as the design iteration simulator, and as it contains all the high fidelity models and the real onboard algorithms, it is later being used for the detailed performance simulations and verification as well. It is also the reference of a correct functioning system for the later autocoded flight software, as all the reference data used for that purpose, will be gen~rated here.
Implement the MVM, PMM etc. in state transition diagrams with a CAE tool.
.1 Implement all the GNC (old/new) in System Build for design and simulation.
" -.1
The next step is to generate automatically the on board software, which is generated from the onboard part of the implementation. In that connection the following shall be addressed:
Implement in external user code part of environmental models. (much can be reused from earlier) .
1
• The interface software to the onboard software, which is not automatically generated must be defined , written and be ready for use. • The style of the automatically generated software shall be ensured by customizing the templates accordingly, which determines how the software will be structured and appear. • The real time scheduler of the operating system will be used and therefore there is not a need for the automatically generated one. Nevertheless it will be generated, and discarded, as this ensures to have complete data consistency between all the blocks and modules. Otherwise this would have had to be done manually, and the whole approach falls to the ground, if one only autocoded in a procedural manner.
,.
Carry out the design of the GNC for performance and stability test etc.
nogo go Generate via Autocode a new version of the flight software and combine with nonauto generated code.
.J. Simulation code adaptation to specific needs for cpmpiler, architecture etc.
~ Download to flight hardware and perform real time performance tests.
On a Sun SparcStation under Solaris 2.5.1 and using the Sun SparcCompiler C version 3.0.1 with the -x02 option the total software size is about 1150 kB, with roughly 950 kB of generated code. User code blocks account for about 60 kB, data definitions for about 60 kB and TMjTC, IjF and scheduling for about 80 kB. Using the -fast option significantly reduces both the size and the execution time, but this compiler option is fragile.
nogo go
Fig. 6. Integrated development of on-board GNC systems from the design phase until the validated flight software. puter and running is about 0.5 hour, including reference data generation, verification and documentation update. This is the point where the method really show its full power.
A better compiler will be able to reduce the code size significantly, and combined with higher level data structures about half the size is expected, taking all the points of section 9 into account as well. This size is estimated some 10-20% larger that a manually coded software, but with much less effort. It is clear that a generic code generator cannot be as optimal as manual coding.
9. LESSONS LEARNED
The execution times for the software is to some extend mode dependent, but for all of them it is possible to stay below ~ 60% of the regular GNC cycle, for the ERC32 Sparc processor, which is quite comfortable.
Before going to the detailed technical points, part of this section is a risk assessment of the whole approach, keeping in mind that this is dealing with safety critical software in connection with a manned space station. The risks identified at the beginning of the project are listed below followed by their evaluation toward the end of the project:
About 15-20% of the software is manually written in order to interface properly with the rest of the onboard system. Turn around time from making a modification e.g a critical interface change until the software is down loaded on the target com-
(1) Qualification of the tool: It is important that the user has full confidence that the tool is qualified, either by a larger set of similar users or by insight into the qualification
358
(2)
(3)
(4)
(5)
(6)
(7)
measures taken by the vendor. In the case of the Matrix~M family of tools there has been reluctance to provide such insight by the vendor. Resources needed by the final system: As the architecture is defined via the system structure laid out in the modeling and simulation tool it is more difficult for the software people to get an idea of the CPU, memory and real time demands; at least seen by someone with a classical development background. It must nevertheless be kept in mind that this will most likely be compensated by the possibility to generate parts of the real code automatically, extremely early in a project, so estimates are not needed in the same manner as before. Bugs in the tool: There are always some bugs in tools, compilers etc., so this is not much different from the classical approach. Bugs were found. Some were easily corrected, some were more difficult. A known bugs list from the vendor would have been very useful, but was unfortunately rejected. One advantage is that the bugs are consistent, which cannot be said in manual programming with many persons involved. Debugging software via graphics : As manual intervention in the generated software is strictly prohibited, identified problems cannot be solved in the classical manner. It will have to be solved either via the code generator templates or via the implementation, which is still not always a straight forward and established way. Configuration management: This is certainly needed for both the software and the implementation. It was not possible with the tool release used in (ATV, 1994), but in the latest release together with another product it is possible and strictly necessary when a multi industrial development is present. Design rules: As the software architecture is driven by the implementation in the modeling and simulation tool, the software people will have to provide to the control systems design people a set of design or implementation rules to follow. Problems can arise if those are not followed, but this is also the case for manual coding, just at a different place in the development process. Monitoring of software performance: It is now more difficult to measure the performance seen from a contractual point of view, as the software and GNC design is somewhat merged. This calls for different ways of allocating wrt. responsibilities.
development in full scale has been quite successful. From that process, a table of recommendations and recording of problem areas will follow: • It is mandatory to issue design and implementation guidelines for the modeling and simulation tool in order to get desired software out. • The modeling and simulation tool can be used very successfully in the beginning to design almost completely the architecture with labels and all interfaces in an electronic forms. Very easy to distribute, use and maintain compared to traditional interface control via documentation. • It is important to evaluate carefully which type of system is suited for implementation in the modeling and simulation tool and what should be implemented directly and what should be attached in external software. Typically time varying Kalman filters are not suited, as there is a lot of matrix algebra and vectors involved in the Ricatti equations. This should conveniently be handled in an external user code block. This problem should nevertheless be releaved in the next tool release as block connections will change from presently scalars only, to vectors. • It is important that GNC designers and software designers work more closely together early in a project and try to obtain understanding of each others fields and constraints. The importance is driven by the fact that the software architecture and other software details are actually partly designed via the implementation in the modeling and simulation tool, which is done by the GNC designers traditionally, and the by fact that the GNC will always have to be designed first, as the software is a medium of implementing the GNC. • For large complex projects it is recommended, at not too late a point, to freeze the release of the design tool and to get an agreement with the vendor that it will be supported during the expected lifetime of the project. Explicit arrangements are needed as only the last 2 releases are on normal support of a vendor to solve problems. • The automatic generation of the real time scheduler is strongly recommended in order to keep data consistency and interfaces clean. When the real time kernel provides a scheduler use that and discard the one autogenerated. If the autogenerated scheduler is used at sublevel it must be ensured it cannot prevent higher level authority. • It is recommended to label properly all connections between blocks and make use of the comment fields to write the module docu-
Beyond this risk assessment it can be said that the whole process and design during this prototype
359
•
•
•
•
mentation fully. This enhances the possibility to generate automatic and useful documentation of the software. It is recommended to use different colors to identify easily different parts of the implementation. It is recommended to build smaller modules, test them, generate the software for them, test it and then proceed to make it more complex. This approach has proven very beneficial. The software standards (ESA, 1994) need some adaptation in order to handle this development approach, as the software life cycle is modified, e.g do the Architectural Design Documents and the Detailed Design Documents no longer exists, but are in the shape of the implementation in the modeling and simulation tool, which can give problems applying the standard directly, as is normally done by requesting the company producing the software. Debugging has shown to be a problem, especially prior to gained experience. As no real debugger exists for the modeling and simulation tool, it can be troublesome to find errors and also are problems at software level not easily traceable back to the implementation. This is still an open area for further investigations.
11. REFERENCES ATV 1994, ATV Rendez Vous Predevelopment. European Space Agency contract. 11 173/94/F /WE Ellenberger R., Ling R., Buscher D., Lacovara J. and Shuler R.,1997. Automatic Generation of Real- Time Ada Simulation for Space Station Freedom. Johnson Space Center, Houston, TX. ESA 1994, Software Engineering Standard PSS05-0 Issue 2. Isi 1995, Xmath, M atrix:z;, Systembuild, Autocode and DocumentIt family of tools. Integrated Systems Inc. Isi-a 1993, Response Times. Vol 6, Issue 1, Integrated Systems Inc. MathWorks 1996, Mat/ab Robust Control Module. Mathworks Inc.
Despite that some of the points above are of negative nature, it has indeed been found beneficial to follow this approach, which in several fields is the trend to future developments. There is always a cost for learning to be paid for the first time, but for experienced tool users there is certainly potential for savings in both cost and schedule of about 50% or more. 10. CONCLUSION The real time onboard GNC system for the ATV spacecraft for the RendezVous and Docking parts have been successfully developed following an integrated tools design approach integrating GNC design, simulation and automatic real time software generation. It has been a full scale development including all facets of a true flight system. The system has been verified with hardware in the loop, fulfills the specifications and it has shown that such a large and complex system is indeed feasible to be developed with such an approach with savings on both cost and schedule; especially after the slope of the learning curve is reduced and savings on cost and schedule of ~ 50% can be expected.
360