Embedded Files
Project Phases
Project Phases
STARLab's systems engineering process follows the traditional requirements and verification process outlined by NASA [1] and the Canadian Space Agency (CSA) [2]. The traditional systems engineering approach enables project teams to be able to plan and manage work relating to satellite development from invisible definition and design, to visible and tangible manufacturing and testing. The different work archetypes are divided into different project phases:
Pre-Phase A - Initial concept studies and development.
Phase A - Expand Pre-Phase A Mission Concept to Potential System.
Phase B - Preliminary Design of Accepted Concept.
Phase C - Critical Design of Accepted Concept.
Phase D - Assembly, Integration, and Testing (AIT).
Phase E - Post-Launch Operations.
Phase F - De-Orbiting and Project Close-Out.
Figure 1 outlines the phases and the project reviews that take place between the team and stakeholders.
Figure 1: STARLab Project Management Phases and Milestones
Requirements
Requirements
The core of the space systems engineering process are requirements, an agreement between stakeholders to deliver a working product that meets mission goals and expectations. The project team initially reviews stakeholder requirements [3][4], expectations, and goals, using these documents as an initial baseline for the team to interpret as mission requirements. These requirements are reviewed and interpreted by subsystem leads to further decomposed into subsystem requirements. Figure 2 provides an overview of how requirements and verification activities are decomposed and organized.
Project requirements are initially created during Pre-Phase A, and provide guidance to a vehicle's technical design. Requirements undergo a continuous process of updating to ensure that the design is achievable. On a quarterly basis, the project team reviews existing requirements to ensure that the team is undertaking work using the same interpretation and understanding of requirements.
Each requirement should have the following information:
ID
Text
Rationale
Parent(s)
Children
Figure 2: Requirements Hierarchy and Decomposition
Figure 3: V-Model
Verification and Validation
Verification and Validation
Verification activites are used to demonstrate that the CubeSat conforms to mission requirements. One useful approach to plan verification activitivies is to use the V-Model shown in Figure 3. The V-Model provides the project team a useful method to plan and execute verification activities during the AIT phase, enabling the team to demonstrate that the CubeSat design will work.
The final step of the V-Model is through stakeholder validation through successful operations. Because there is no ethical or commercially available method to return an in-flight CubeSat, first time success will be the main method of validating project definition.
Note that verification activities can be undertaken as early as Phase B through review of technical design and documentation. Incorporating early and frequent verification activities creates many opportunities to identify design flaws, missing features, or other potential non-conformances.
Requirements Organization and Nomenclature
Requirements Organization and Nomenclature
The team decomposes the mission level requirements into different subsystem requirements groups, providing guidance in developing the technical design of the CubeSat. Each subsystem lead is responsible for decomposing, updating, and maintaining their respective subsystem's requirement. To ensure a thorough and meaningful requirement verification approach, it is important to maintain a thorough record of the parents and children of each requirement. The final step of decomposition is creating a verification activity child that will demonstrate compliance with our requirements, in accordance with our V-Model. Figure 4 provides a visual outline of our requirements hierarchy.
Figure 4: Requirements and Verification Hierarchy
Each subsystem groups created children requirements, using their respective subsystem's project acronym, shown in Table 1. The requirement group acronyms are used throughout the project for identification of requirements, verification activities, and design documentation.
If a subsystem requires another subsystem to make accommodations (i.e. structure requires another subsystem to be below a certain mass), an Inter-Subsystem requirement (R-INT) is created. R-INT is a special requirements group that allows subsystem teams to either push or pull requirements from another team, allowing for a useful method to monitor all inter-subsystem needs.
When recording requirements, the requirement ID will be followed by a four-digit number (e.g. R-YYY-0010, R-YYY-0020). Table 2 outlines the requirement definition, and appropriate interpretation. Should a requirement be introduced in between other requirements, the last digit will be used.
Table 2: Requirements Nomenclature
Table 1: Requirement Groups
Verification Types
Verification Types
The final step of the systems engineering process is to demonstrate compliance with project requirements through verification activities, ultimately meeting all mission requirements. We demonstrate compliance with mission requirements through Roll-Up, or the philosophy of showing compliance to the parent by demonstrating compliance with all children requirements. To accomplish Roll-Up verification, the team creates verification activities as children of subsystem requirements through one of four verification methods:
Review of Design/Documentation: Determines conformance to requirements by examination of technical drawings, CAD models, or design documentations (such as component specifications or qualification reports).
Analysis: Evaluation of data by generally accepted analytical techniques to determine that the item will meet specified requirements. Techniques include calculations and simulations.
Inspection: Determines conformance to requirements by the visual examination of the design item using standard quality control methods, without the use of special laboratory procedures or equipment. Activities include measurements (dimensions and mass) and visual inspections of features.
Test: A verification method in which technical means, such as the use of special equipment, instrumentation, simulation techniques, or the application of established principles and procedures are used for the evaluation of the system or system components to determine compliance with requirements.
Verification activities are undertaken throughout the project, with review and analysis being the primary verification activities during phases B and C. Phase D, also known as the Assembly, Integration, and Test (AIT), has the majority of the test and inspection activities, to demonstrate a functioning final product before launch.
Verification Activity Elements
Verification Activity Elements
To create meaningful verification activities that demonstrate compliance with requirements, activities need to outline [5]:
Identification - Verification ID in accordance with requirement naming convention.
Activity Goals - In addition of the requirement that will be verified, the verification activity needs to be clear about the acceptance criteria. There needs to be a measurable and observable metric that can be used as evidence that the CubeSat meets the goal requirement.
Activity Details - Step-by-step instructions that an operator needs to undertake the activity, providing necessary and important guidance for the activity operator. This is especially critical if the activity operator is not the subsystem lead.
Required Support Equipment - A short list of tools, test equipment, software, or facilities needed to complete the test.
Activity Parameters - This is critical information for tests and inspections, and can include, but not limited to, temperature ranges, vibration profiles, test duration, among others.
Activity Log - A place to record results, notes, or a checklist that can be completed.
Valispace
Valispace
The team uses Valispace, a requirements and verification management service, to control and organize our project. Guests to this website are welcome to review and study our requirements and verification activities using the link below.
Guest Account:
Username: Guest
Password: spaceishard
Valispace Instructions
Valispace Instructions
The team uses a student license of Valispace to manage project requirements, providing a useful platform to conduct requirement reviews. Each subsystem lead is responsible for maintaining their respective subsystem requirements, and communicating with other leads to create meaningful inter-subsystem requirements.
Note that although Valispace implements many features and tools for analysis, simulations, and component design, the team opted to instead use the project Wiki to be the main form of documentation and team communication. As such, the team includes internet links in Valispace for important project documentation, streamlining transfer of knowledge to the team.
The Valispace Instructions Sub-Series aims to provide all stakeholders a quick-start guide to use and review the information contained inside the requirements registry. New members and external users are welcome to use the guest account.
Figure 5: Opening Menu
Figure 6: Projects in the Iris Workspace
When you first enter Valispace, you will see the opening menu on the left hand side of the screen, as shown in Figure 5. For your convenience, the important sections have been highlighted:
Valispace Project Drop Down Menu - Valispace provides users with different projects and workspaces to experiment and monitor work. To view a given project's requirements, select the relevant project from the Training Workspace drop down menu. For example, to view the Iris requirements, ensure you are in the Iris project (ManitobaSat-1) as shown in Figure 6.
Valispace Modules - Valispace provides a variety of tools to manage and control a projects. Available modules include simulations, analysis, and components.
Requirements Module - The requirements module contains the requirements registry, and is the only feature used by the team. This module provides the structure needed to ensure thorough requirement tracking and verification.
Requirements Page
Requirements Page
The Valispace requirements module is the core of the team's project requirements and verification tracking system, providing all the information required of the team to find and review relevant requirements. The team has grouped each requirement in accordance with the systems engineering hierarchy, allowing individual subsystems to create and manage their own requirements and verification activities. The team's system engineering lead manages the mission level and the inter-subsystem requirements to ensure design harmony between subsystems. Figure 7 provides the elements of the requirements group page.
Figure 7: Requirement Page
Valispace provides the team with different methods to document and organize information relating to requirements. Below is a description of the most common requirements related columns used by the team, corresponding with the call-out number in Figure 7.
Requirements Tab - This tab provides the view currently provided in Figure 7, providing the user a view of recorded requirements.
Connections Tab - This tab provides a visual representation of how all requirements or specification (subsystem requirements) are linked.
Status Tab - This is a new feature in Valispace as of the 28th of October 2020, but provides a useful outline of the verification status of all children in the project. This will be reviewed and investigated further by the team.
Requirement Identifier - This column provides the requirement ID's in accordance requirement and verification activity naming convention.
Requirement Text - This column provides the requirements text, following "Shall," "Should," and "May" conventions.
Requirement Rationale - This column provides the reasoning or parent external requirements for mission level requirements.
Parent Requirements - This column provides the parent requirement for all subsystem and inter-subsystem requirements, and verification activities.
Child Requirements - This column provides the child requirements for all requirement groups.
Verified Children - This column provides the number of children requirements and verification activities that have been verified.
Tags - This column provides tags that facilitate sorting. It is primarily used to identify when verification activities occur (Phase A, B, etc.)
Page Settings - This drop down menu provides users to be able to edit visible columns, export table into either an CSV or XLSX file. Figure 8 provides the expected view.
Figure 8: Requirements Page Options
Figure 9: Sample Requirements Grouping
Requirements and verification activities are divided into their respective subsystem folders, which organizes entries as either requirements or verification activities, as shown in Figure 9. Note that due to the nature of mission level requirements having no parents, and inter-subsystem requirements being an interim group, they have been allocated into the "Top_Level_Group."
Users can also access more requirement specific information by clickling on the requirement ID, discussed in the next section.
Requirements Details
Requirements Details
You can click on the requirement ID to access a details drop down menu, shown in Figure 10. The details page provides an easy to use method to review links, change log, and reference images for requirements and verification activities.
Figure 10: Requirements Detailed Page
This details page provides a few options to find important information detailed below with the corresponding call out number:
Requirement Entry - This is the requirement entry from the main requirements page.
Information Tab - This provides more details for the requirement if entered, such as owner and attached images.
History Tab - This tab outlines the version control for this requirement, including who and when enacted the change.
Properties Tab - This tab allows users to record and use properties (such as mass or volume) for different Valispace functions. Note that these features are not used by the ManitobaSat-1 team.
Children Tab - This tab provides a list of all children requirements, including text, children, and verification status. Note that you can change the visible columns inside of this requirements tab.
Connections Tab - This tab provides a list of all related requirements in a tree diagram format.
Files Tab - This tab provides a list of all files and documents attached to this requirement. Note that this feature is not used by the ManitobaSat-1 team.
Requirement Images - Images can be added to individual requirements. Tables and sample images from external stakeholder requirements have been added in this fashion and made available to all team members.
Verification Activities
Verification Activities
Verification activities are used to demonstrate the CubeSat's compliance with project requirements and it's capability to meet mission goals and expectations. Requirements need to be clearly defined in the pass fail criteria, if the test has been undertaken, and if the results demonstrate compliance. Figure 11 shows a verification group with the most common visible columns.
Figure 11: Verification Activity Common Elements
Because the team uses the Valispace requirements interface to control verification activities, many of the functions options and columns presented in the requirements page and details sections are still available to users. However, because verification activities differ from requirements, different information is needed to understand and interpret the current state of the project. Common elements used by the team for verification activities are detailed below with corresponding call-out numbers in Figure 11.
Verification ID - This column provides the requirement ID's in accordance requirement and verification activity naming convention.
Verification Text - This tab provides a visual representation of how all requirements or specification (subsystem requirements) are linked.
Parent Requirements - - This column provides the parent requirement for all subsystem and inter-subsystem requirements, and verification activities.
Compliance Status - This column provides the current compliance status of the verification activity. Supporting evidence is documented in the "Verification Comment" column (item 6).
Compliance Comment - This column is used for additional documentation for the compliance status of the activity.
Verification Method - This column provides the verification method used (Review of Design/Documentation, Analysis, Inspection, Test).
Components - To enable the verification activities in Valispace, requirement groups need to be linked to components. The team has created general subsystem components in Valispace that can be found in the Components module, with the only purpose to enable verification content.
Status - This column demonstrates if the verification activity has been completed (shown as verified). Other options include ongoing, or partially verified.
Verification Comment - This is the main column where the team includes links or directions to evidence for the status and compliance of the verification activity. All verification reports are collected in the Verification Reports section in this wiki.
All verified and compliant activities are reflected in their respective subsystem requirements group, and appear as an entry in the number of children verified column, shown in Figure 12. This cascades into the top level requirements, providing evidence of verification through roll-up to mission level requirement.
Figure 12: Number of Children Verified Example
References
References
[1] NASA Systems Engineering Handbook, Rev 2
[2] CCP Essence of Success (Webinar 1)
[3] NanoRacks CubeSat Deployer Interface Definition Document
[4] Canadian CubeSat Project Design Specifications
[5] CCP AIT Webinar Part 1
Page updated
Google Sites
Report abuse