This software requirements change management case study focuses on a topic that is easily overlooked at the outset of any project, when optimism is high and the notion of changing requirements the last thing on anyone’s mind. But the development of anything as complex as a business Jet Power Control Unit (JPCU) is unlikely to be without incident. Being responsive to such things can be the difference between timely completion of a project, and a project management nightmare drifting towards the left of the Gantt chart.
A JPCU is a system designed to ensure smooth power switching between external power supplies and Aircraft Generator Control Units (GCUs). It is responsible for management of power within the jet, and manages hundreds of analogue and digital signals to allocate a power source (external AC, external DC, engines….) The software consists of thousands of lines of logic to evaluate the status of power throughout the aircraft, and act upon it. It is able to detect fault conditions including short-circuits, over-voltages, under-currents and event upsets.
Established in 1998, CRITICAL Software provides systems and software services for safety, mission and business-critical applications. CRITICAL work with clients from a diverse range of sectors, including aerospace, automotive, defence & security, energy & utilities, medical, railway and many more. Despite this diversity, CRITICAL’s clients share a common requirement for the most demanding quality standards in software safety, performance and reliability.
The High Integrity Systems division (HIS) of CRITICAL software has been committed to safety critical systems development, verification and validation for over 20 years. Vitor Conceição has seen most of the division’s aerospace system developments during that time, whether as project technical manager, consulting engineer, or currently as principal engineer. That experience has highlighted one thing above all. “Change requests represent a striking common factor to all of those projects” explained Vitor. “And they are invariably frequent, unexpected, and demand a very short response time”
The HIS division were introduced to the LDRA tool suite because it was a client’s tool of choice for their Business Jet Power Control Unit (PCU) project (sidebar). However, CRITICAL’s experience of the tool suite has meant that they are very pleased to have been introduced to it.
Given the pivotal nature of the PCU in the functional safety of the aircraft, it is no surprise that the project was subject to DO-178C, “Software Considerations in Airborne Systems and Equipment Certification” – the primary document by which the certification authorities such as FAA, EASA and Transport Canada approve all commercial software-based aerospace systems.
DO-178C defines the mechanism used to categorize the risk associated with each airborne system resulting in the assignment of a “Software Level” (also known as the “Design Assurance Level” (DAL)). The Software Level is determined from the safety assessment process and hazard analysis by examining the effects of a failure condition in the system. The PCU developed by CRITICAL was assigned level A, implying that a failure of the system would be a catastrophic failure condition for the aircraft.
Systems comprised of electrical and/or electronic elements have been used for many years to perform safety functions in most application sectors. The aerospace industry has long been a thought leader in this field with its DO-178 and related standards, but the oil and gas, medical device, automotive, and many other sectors all rely heavily on similar functional safety principles.
Computer-based systems (generically referred to as programmable electronic systems) are being used across application sectors to perform non-safety functions and, increasingly, to perform safety functions.
Formalized functional safety processes are fundamental to the enabling of complex technology to be used for safety-related systems. They provide the assurance that the safety-related systems will offer the necessary risk reduction required to achieve safety for the equipment.
CRITICAL’s HIS division applied both the LDRA tool suite’s Static and Dynamic analysis capabilities to help achieve their certification aims.
It is a requirement of DO-178C level A that coding standards are specified and adhered to. The TBvision component of LDRA’s tool suite automates the “inspection” of the source code, making compliance checking easier, less error prone and more cost effective, by comparing the code under review with the rules dictated by the chosen software coding standard. Non-conformances are highlighted as required by DO-178C section 6.4.3d. The tool suite can also assess the complexity of the code under review to ensure that it stays below a safe threshold for the system, and its data flow analysis facility can be used to identify any uninitialized or unused variables and/or constants as specified by DO-178C section 6.4.3.f.
In contrast to static analysis, dynamic analysis involves executing the Executable Object Code (EOC) piecemeal or in its entirety, using a target environment representative of that to be deployed in the completed application. This execution is used to provide evidence both of correct functionality, and of the parts of the code exercised (“structural coverage”).
DO-178C discusses both of these concepts, identifying objectives to achieve test coverage of high and low level requirements, and to achieve appropriate test coverage of both the software structure, and the data and control coupling.
The “test cases and procedures” referenced in the standard could include low-level tests (sometimes referred to as unit tests), integration tests, or system tests, and probably a combination of all three.
Low-level tests are designed to verify the implementation of low-level requirements using the TBrun component of the LDRA tool suite. Test procedures need to be authored, reviewed, and executed to ensure the software does not contain any undesired functionality. Low-level tests can then be executed on the target hardware as specified in the Software Verification Plan (SVP). Once the test procedures are executed actual outputs are captured and compared with the expected results, and pass/fail results reported.
Although this implies a smooth and trouble-free development process, as Vitor observed that does not tell the whole story – which is why he highlighted TBrun as being especially beneficial to CRITICAL. “The on-target test capabilities are especially important to us” he observed. “The LDRA tool suite’s ‘test case files’ store all the settings required for test re-execution, including test data and environment/target set-up. This is key because it makes regression testing in response to the change much more efficient, especially once the project enters change control.”
To put that into context, Vitor estimates that the regression testing capabilities alone have saved around 15% of the time previously spent on dealing with change.
The experience the CRITICAL HIS team have gained by using the LDRA tool suite on the Business Jet PCU project has certainly turned them into enthusiasts for the product. “Installing and applying the tool suite to our development processes was easy, and learning how to use it took less time than we imagined.” said Vitor. “We now apply more analysis techniques as a result of using the LDRA tool suite, which in turn has seen an improvement in code quality.”
There is little that the team would have changed with hindsight. One exception centered around the presentation of Data and Control coupling coverage in the tool suite. ”The presentation of the data could be presented in a way that is more directly related to the requirements of the DO-178C standard” said Vitor. LDRA is always keen to respond to the needs of its customers, and suggestions and requests of this sort help to drive the policy of continuous product improvement.
The application of the LDRA tool suite has been a great learning experience for everyone involved, and the team are excited by its ongoing potential. “Although the tool chain was specified by our customers for this project, we certainly anticipate deploying it in our future work” said Vitor. ”Looking forward, we anticipate ever-increasing complexity in the applications we are involved with.” He concluded, “We expect the LDRA tool suite to make us more efficient at dealing with that complexity, reduce ongoing support costs, and hence to make us more competitive in the future.”
Mark Pitchford has over 30 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally. Since 2001, he has worked with development teams looking to achieve compliant software development in safety and security critical environments, working with standards such as DO-178, IEC 61508, ISO 26262, IIRA and RAMI 4.0.
Mark earned his Bachelor of Science degree at Nottingham Trent University, and he became a Chartered Engineer over 35 years ago. He now works as Technical Specialist with LDRA Software Technology.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707