Software Requirements and Design Process in the Aerospace Industry University of Waterloo, SYDE 161 Guest Lecture October 5, 2011 Leif Bloomquist P.Eng (SYDE ‘97) Senior Software Systems Engineer, Space Missions
Jun 18, 2015
Software Requirements and Design Processin the Aerospace Industry
University of Waterloo, SYDE 161 Guest LectureOctober 5, 2011
Leif Bloomquist P.Eng (SYDE ‘97)Senior Software Systems Engineer, Space Missions
Presentation OverviewExample projects: Canadarm, Canadarm 2, Phoenix Mars
Lander, neuroArm
The Software Process Overview Requirements Documentation Other important considerations
A couple of cool videos!
2
April 13, 2023 3
Early Steps: Canadarm
Credit: NASA
Launched in November, 1981 on STS-2
Power Usage Max 1,000 watts plus 1,050
watts of heater power Typically less than 300 watts,
or 5 light bulbs. Construction
Aluminum, stainless steel, carbon composite.
Thermal Thermostat controlled
electric heaters and thermal blankets
Payload handling 266,000 kg (a fully loaded
Shuttle vehicle)
4April 13, 2023Hubble = 11,100kg
April 13, 2023 5
Translational Hand Controller (THC): Right, up, down, forward, and backward movements of the arm
Rotational Hand Controller (RHC) Controls the pitch, roll, and yaw of the arm
Canadarm2 Arrives (2001)17.6m long7 jointsMass: 1,800kgHandling Capacity: 100,000kg2 latching end effectors (“hands”)Force-moment sensing capabilityRelocatable – can travel end-over-
endElectrically redundantOn-orbit or Ground-based controlPP: 2kW | Prms: 1360W
6April 13, 2023Credit: NASA
Canadarm 2
Space Station Assembly
April 13, 2023 7Credit: NASA
Robotic Work Station aboard ISS
Dextre
3.5 m (12 ft) long
Two manipulator arms, each with 7 joints
One body roll joint
Each arm fitted with an Orbit Replacement Unit/Tool Change-out Mechanism (OTCM)
Force-Moment sensing capability
600 kg (1300 lbs) payload handling capacity
One Latching End Effector
Four special tools, carried in Tool Holder
8April 13, 2023Credit: NASA
Phoenix MET
9
• Launched in August 2007• Lands on Mars on May 25, 2008• Meteorological station to assess the interaction of
surface ice with the atmosphere– Zenith-pointing LiDAR to characterize Martian climate
and atmosphere (cloud, fog and dust properties)– Temperature and pressure sensors
Phoenix Mars Lander
Snow on Mars
"You cannot study a surface and an ice layer without knowing the atmosphere above it, and we have a huge volume of data that describes weather for the entire time we conducted surface operations," Smith said. "This is one of the major accomplishments of the mission." At the end of the surface mission, Phoenix saw, for the first time, water as snow falling to the surface Mars and frost on the ground. Falling snow was a real surprise – Peter Smith, Phoenix PI
But the really amazing data came from the LIDAR instrument… In short, they watched it snow. (Timmer, Ars Technica July 2009)
neuroArm
Image guided robot operates inside of 1.5T MRI for Intra-operative imaging and guidance
Successful procedures performed on patients at Calgary Foothills Hospital
Performance Goals achieved:
• 15 Hz closed loop bandwidth for immersive control – no delay or overshoot
• 50 micron tip position control• Haptic feedback – 2g force sensing• 1mm tool to image registration accuracy
How do these critical, complex systems come together?
The Software ProcessThe aerospace industry generally follows MIL-STD-498 as a guideline for its
software process and documentation. United States military standard whose purpose was to "establish uniform
requirements for software development and documentation." It was released Nov. 8, 1994
Each company has its own customizations.
The process is tailored per project, with customer approval.
Superceded by IEEE 12207.0 "Standard for Information Technology – Software Life Cycle Processes “ in 1998, but many organizations have kept with the older format.
The Software Process 1. Develop an operations concept
High level, what does the system need to do and how will it work? High-level use cases
2. Develop System requirements What will the System be expected to do?
3. Derive and allocate subsystem requirements Begin to establish detail, what parts will cover each function? Requires an initial system architecture concept
The Software Process 4. Derive detailed requirements for each discipline (software,
mechanical, electrical) More detailed use cases These are actually implementable and testable
5. Design a system that meets these requirements For software: Unified Modeling Language Prototyping and documentation Interfaces
6. Implement – Write your code (manufacture the part, etc…) If the previous steps were done satisfactorily – this can be the shortest
phase.
The Software Process 7. Validate and Verify (“Test”)
Test to the requirements – not the design Start at lowest level and work your way up (next slide) Verification vs. validation
8. Release and Maintain See upcoming section on documentation
9. Iterate as necessary See upcoming section on development methodologies
Customer reviews and milestones at each step
The Software Process “V Model”
Software Development MethodologiesWaterfall
Fully complete each stage of the process before moving on Once each stage is complete, never go back Suited for high-risk projects with multiple stakeholders (space stations, nuclear
reactors) Nearly impossible in practice
Iterative Reflects reality – iterations are always required Process for feeding findings from later stages back into the earlier stages
(Engineering Change Notices, etc.) Regression Tests
Agile A huge topic, currently “in vogue” in the software industry Takes Iterative to its extreme, each part of the system is developed rapidly Apply to safety-critical systems with caution
DefinitionsWhat are requirements?
IEEE (1) A condition or capability needed by a user to solve a problem or achieve an objective
IEEE (2) A condition or capability that must be met or processed by a system or system component to satisfy a contract, standard, specification or other formally imposed document
Purpose of Requirements Engineering To achieve agreement on what is to be produced To decrease ambiguity and increase consistency and completeness To do this, understand the customer need
If you do not understand what the customer wants you will fail Seek first to understand and then to be understood
To document the agreed set of requirements It is not enough just to understand what the customer wants, it is also necessary to
record the understanding Shared vision To identify key issues: requirements with strong influence on cost, schedule, functionality,
risk or performance To provide a basis for system design To provide a reference point for system validation What if there are problems in the customer provided system specification? Communication
Benefits of Good RequirementsAgreement among engineers, customers and users on the job
to be done and the acceptance criteria of the delivered systemA sound basis for resource estimationImproved system effectiveness factors
What if the customer does not specify these?The achievement of goals with minimum resources (less
rework, fewer omissions and misunderstandings)Reduced “expectation gap”
Problems with Bad RequirementsCreeping user requirementsUnplanned requirement changes degrades qualityAmbiguous requirements lead to ill-spent timeIncreases expectation gap
Customer and engineer have different opinionsNeeds of user are overlooked
Fuzzy requirements make planning difficultThe product may not be fit for useCan (will) lead to cost and schedule overruns
Why is it hard to write good requirements? Lack of knowledge that good system requirements are essential to the
development of a good systemThey are difficult to write: sophisticated problem solving is required to
produce a good statement of requirementsEngineers lack training in requirements engineering It is next to impossible to capture user needs completelyDesire to truncate the activity and “progress” to the next activity: schedule
pressureCustomer failure to cooperate in effectively verifying that the requirements
are correctAssumptions are made which are not documented or discussed “How” instead of “What” is writtenWe don’t pay attention to lessons learned
Requirement Attributes Good requirements have the following attributes:
Necessary Unambiguous Complete Verifiable/Testable Consistent Maintainable Correct Implementation-free Concise Feasible Understandable Traceable
Let’s try an example
Traceability Traceability is key to ensure the system “hangs together”.
Upward traceability (low-level requirements to system requirements) Answers “Why are we implementing this particular requirement? Where is it derived
from?”
Downward traceability (system requirements to lower level requirements) Ensures that none of the system-level requirements get missed
There are tools to help you manage traceability: IBM’s ReqPro Artego’s Artisan Studio - Also traces to UML design (Free version Uno) Many others
Modern complex systems can have thousands of requirements
Verbiage“Shall” indicates a mandatory requirement“Should” indicates a preferred but not mandatory alternative“May” indicates an option“Will” indicates a statement of intention or fact
These are often contractual
Common Problems
Making bad assumptionsWriting implementation (HOW) instead of requirements (WHAT)Describing operations instead of writing requirementsUsing incorrect termsUsing incorrect sentence structure or bad grammarMissing requirementsOver-specifying
Key Documents
Operations Concept DocumentSystem Requirements SpecificationSoftware Requirements Specification (for each unit)Software Design Document (for each unit)Version Description Document (for each unit)Verification Plans and Procedures (per unit, interface and
system-level)
And the most important…
Interface Control DocumentDetails of the interface between two entities (subsystems,
computers, devices, organizations…)Roles and responsibilities of all partiesCan be data, mechanical, electrical, organizational…
Entity A Entity BInterface
Importance of ICDs
But when it all comes together…
April 13, 2023 32
Questions?