Satellite Configuration Control

 

Kevin McMahon

Nov 9, 2003

CSMN 661 9040

Fall 2003

 

 

 

 

 

Submitted to Dr Jon W. McKeeby as fulfillment of the Lab Project Summary Requirement for Relational Database Systems, Fall 2003.
Abstract

 

Configuration Control Database for Satellite Operations

Kevin McMahon

 

Successful satellite operations require many software and hardware components, both on the ground and in space.  It is a necessity to have an accurate snapshot of these components.  Any time that a change is requested there should be an approval process.  If a request is approved by all the appropriate levels, it then needs to be completed and clearly documented.  A comprehensive system for tracking the configuration of all the software and hardware will ensure that only the most current and appropriate components are utilized.  A configuration control database should fill this role perfectly.


            Running a successful satellite operation requires a clearly defined list of the many components that make up the ground segment of the spacecraft operations.  The arrangement of these various components is the configuration of the ground system.  “How we handle that arrangement of things is called configuration management.” (Rickbaugh, 1994)  Configuration management is actually two separate functions.  The first is clearly defining the list of components.  The second is assuring that over time, this documentation still reflects and accurate picture of the system itself. (Rickbaugh, 1994)  Therefore, any time a component is modified it should be documented. 

 

            There are commercial products available that serve this purpose.  Some are specifically designed for the end user and some are more generally designed and are merely tailored to each individual end user.  If an enterprise is looking at a particular software tool for their CM needs, there are certain things they should consider.  Will this tool meet not only your current needs, but is it scaleable to meet your future needs?  Will the tool allow geographically distributed use?  How difficult will the product be to setup and maintain? (Hague, 1995)  Another point to consider would be the cost of the tool; a small company may not be able to afford the best available software given their budget levels.

 

            A company with a small budget and a talented workforce might choose to design their CM tool in-house.  This can save considerable amounts of money and still have many benefits.  The tool can be designed to handle the specifics of the system it is managing, unlike a large commercial product which will have many unused functions.  Since those designing the tool will be the same ones maintaining the system, the tool will be designed with thought given to ease of maintenance.  The tool can be designed specifically to allow for the projected growth of the system so scalability should not be an issue.

 

            A generic spacecraft CM tool could be easily implemented using a database.  With the searching capabilities of a well-designed database, components and their changes could be easily monitored and maintained.  To complete both functions defined earlier for configuration management the database would have to meet several requirements.

 

            The first function of CM given earlier stated that a clearly defined list of components must be obtained.  The database should start with a baseline record of all software and hardware used in the daily maintenance of the satellite.  The baseline must include the following components:

1)      Software or hardware tool name.

2)      Version (software) or model (hardware) number.

3)      Designer (software) or Manufacturer (hardware).

4)      Active date for the version/model number.

Knowing all of this information clearly defines what is currently used and is therefore the baseline given for the rest of the mission lifetime.

 

            To meet the requirements of the second function of CM, ensuring that this database accurately reflects the current configuration, we need to know more information on each component and have some relationships in our database.  Any time an individual wants to make a change to one of the hardware or software components that make up the system, a change request must be generated.  This change request must contain certain information:

1)      A change request number.

2)      Person requesting change.

3)      Justification for the change.

4)      What the change actually does.

5)      Date request made.

6)      Approval or denial of request.

7)      Date request approved/denied.

8)      Person responsible for implementing the change.

 

Since each change must be requested and approved before it can be implemented, there must be a process for reviewing change requests.  Therefore we must add a new table to our database.  This table will list people responsible for approving and/or denying change requests.  This is commonly known as a Configuration Control Board (CCB).  All of the change requests do not necessarily require CCB approval.  Some may only require the approval of a mission engineer (such as simple procedure changes).  This will actually require the addition of two tables.  One table will contain the CCB members and one will contain a list of the Flight Operations Team (FOT) members.  This will also require a relationship between each component and either the CCB board or the FOT showing who is responsible for approving changes to this item.

We have already stated that each change request must have both a change requester and a change implementer.  Sometimes these will be one and the same; sometimes it will require more than one individual.  A change request will usually be initiated by a member of the FOT but occasionally will be initiated by a CCB member.  This will require a relationship between every change request and either a CCB member or an FOT member.  The change implementer can also be one of two individuals.  Simple software changes may be completed by the FOT, but more complex and/or dangerous changes will require the use of software engineers.  This requires the addition of another table showing the various software engineers that can contribute to the project.

Having all of the above information available at a moments notice also has security benefits.  According to a survey completed by the Yankee Group in 2002, many enterprises have experienced unauthorized changes to their desired configuration. (Olson, 2003)  Having an accurate record of what is on your system, makes it easier to 1) detect that an unauthorized change has been made and 2) correct that change. 

 

Another benefit of an accurate database is related to the knowledge of everything running on your system.  Systems can, over time, become bloated as new software and/or hardware replaces outdated components.  Sometimes these old components are left intact on the system which can slow the efficiency of the system and or create a higher likelihood of a system failure.  William Jackson uses VeriSign’s networks as an example: “users have the software that they need, but only that.” (Jackson, 2003)  When multiple users share equipment it can sometimes be difficult to know what is being used on the system and what is not.  With a complete understanding of all of the components of our ground segment, it should be easy to determine which software/hardware components are actually used and are essential to the daily operations.  This allows for the system to run with the minimum amount of components, thus bloating of the system can be minimized helping to ensure a healthy system.

A database created in this fashion will allow both of the primary functions of CM to be met.  Not only will we always have an accurate snapshot of what is currently active on the system, we also will be able to look into the past.  This database will provide the ability to look at any change made to the system, see why it was made, what it changed, who approved it and also who implemented it.  If there is any question later about the system, these records will be vital to understanding what is on the system and why it is set up the way that it is.


References

 

Wreden, Nick (1996, Oct 28). Mission: control. Communications Week n635.             p65, retrieved Oct 14, 2003 from Computer database.

 

Olson, Bob (2003, July 1). Managing Configuration: Command and Control –   Improper configuration changes can wreak havoc. Protect your network     from troublesome tweaks. Network Magazine, p46, retrieved Oct 14, 2003      from Computer database.

 

Jackson, William (2003, June 23). Configuration control comes before patch     management. Government Computer News v22 i16.  p30, retrieved Oct      14, 2003 from Computer database.

 

Rickbaugh, Jim (1994, August). Configuration management: the hidden friend in             the business of reengineering. Industrial Engineering v26 n8.  p20,       retrieved Oct 14, 2003 from Computer database.

 

Hague, Tani (1995, March 1). CM tools: do your homework before signing on the        dotted line. Computing Canada v21 n5. pS36, retrieved November 9, 2003             from Computer database.

 

 

Home Outdoors  Various School Projects Rat Babies Wacky Test Results Contact Kevin McMahon