Modifiability refers to the ability of a system to be easily changed or modified without negatively impacting its functionality or stability.
In the context of DO-178C software lifecycle data characteristics definition;
When we say the information is modifiable, it means that the data is structured and styled in a way that allows changes to be made completely, consistently, and correctly while preserving the underlying structure.
Structured Information:
Lifecycle data should be organized in a manner that maintains a clear, logical structure.
This allows for any necessary modifications to be integrated without disrupting the overall framework. For example, requirements should be clearly documented, with each requirement linked to corresponding design elements and test cases, so that if a change is made, the impact can be assessed and updated throughout all relevant lifecycle stages.
Complete Modifications:
When modifying software, all related lifecycle data must also be updated to reflect the change comprehensively. This means ensuring that not just the code but also the requirements, design documents, test cases, and other artifacts are all revised to maintain consistency and completeness across the project.
Consistent Updates:
Consistency is key in maintaining the integrity of modifiable software. Any changes must be consistently applied across all affected components. For instance, if a requirement is modified, all design elements, code, and tests related to that requirement should be updated accordingly. Configuration management systems play a crucial role in maintaining this consistency.
Correctness:
Changes must be made correctly, ensuring that the modified software meets all the required standards and does not introduce new errors. Verification processes, including testing and reviews, must be conducted to confirm that the changes are implemented accurately and do not negatively impact the system's functionality or safety.
Retaining Structure:
The structure of the software and its lifecycle data must be preserved during modifications. This involves maintaining the original architecture and design principles, ensuring that any modifications integrate seamlessly into the existing system without compromising its structural integrity.
Let's focus to three "C" s
Completely
- Definition: Making a modification "completely" means that all aspects of the change are addressed across the entire software lifecycle, ensuring that nothing is overlooked.
- What To Do?: Let's think about an update is required for an aircraft's autopilot system to handle a new maneuver mode. To implement this completely, the change must be reflected not just in the code, but also in the requirements documentation, design specifications, and test cases. If the new mode requires additional sensor inputs, these must also be fully integrated into the system's architecture, ensuring that every aspect of the system that interacts with this new mode is updated.
- What Happens if Not Complete: If the update is incomplete, certain components, like sensor inputs or communication protocols, might not be updated, leading to potential system failures or unsafe operations during the new maneuver.
- Aircraft Accident Examples!:
- Imaginary Example: Suppose an update is made to the autopilot system to include a new flight mode, but the corresponding update to the software that manages flight displays is missed. The new mode may be functional, but the pilots would not be able to see or understand the current mode on their displays.
- Real-World Example: Boeing 737 MAX Crashes (Lion Air Flight 610 and Ethiopian Airlines Flight 302) The Maneuvering Characteristics Augmentation System (MCAS) was introduced to the Boeing 737 MAX to prevent stalls, but there was a lack of comprehensive information provided to pilots and insufficient integration of the new system into training programs. The MCAS could activate based on erroneous sensor data, causing the aircraft to enter a nosedive. This was not fully addressed across all relevant systems and procedures, leading to two tragic crashes.
Consistently
- Definition: Making a modification "consistently" means that the change is applied uniformly across all relevant parts of the software and its documentation, ensuring that there are no discrepancies.
- What To Do?: Consider a modification to change the maximum allowable altitude in the flight management system (FMS). Consistency requires that this new altitude limit is updated not only in the code but also in all related user interfaces, warning systems, and documentation. The maximum altitude should be consistently reflected in the data fed to the cockpit displays, autopilot logic, and any altitude-based alerts.
- What Happens if Not Consistent: If inconsistencies arise, for instance, if the altitude limit is updated in the code but not in the warning system, the aircraft might operate at altitudes that trigger incorrect warnings or, worse, might not warn the pilots of approaching limits, compromising safety.
- Aircraft Accident Examples!:
- Imaginary Example: Consider an update to a flight control system that changes how altitude is calculated. If the code is updated but the associated safety checks or monitoring systems are not, inconsistencies between the control system and the monitoring systems could cause errors or unexpected behaviors.
- Real-World Example: Air France Flight 447 In this accident, inconsistencies in the aircraft’s response to unreliable airspeed data contributed to the crash. The pitot tubes, which measure airspeed, iced over, causing inconsistent data to be fed into the flight control system. The autopilot disconnected, and the crew was left with conflicting information. The flight control systems did not handle the situation consistently, leading to the aircraft stalling and ultimately crashing into the Atlantic Ocean.
Correctly
- Definition: Modifying software "correctly" means that the change is implemented accurately, following all relevant standards and procedures, and verified to ensure it meets the intended requirements without introducing new errors.
- What To Do?: Suppose a software patch is needed to correct an issue in the landing gear control system. Correctness involves implementing the fix precisely according to design specifications, followed by thorough testing to ensure the issue is resolved without introducing new problems. This could involve running regression tests to confirm that existing functionality is not affected and conducting specific tests under various scenarios (e.g., different speeds, weather conditions) to verify the fix.
- What Happens if Not Correct: If the fix is not applied correctly, the landing gear might fail to deploy or retract as expected, potentially leading to catastrophic outcomes during landing. Incorrect changes could also lead to unpredictable system behavior, reducing the overall reliability and safety of the aircraft.
- Aircraft Accident Examples!:
- Imaginary Example: Imagine a scenario where a software update is applied to the fuel management system, but the update is incorrectly implemented, leading to the miscalculation of fuel distribution during flight. This could cause an imbalance, potentially leading to control issues during critical phases of the flight.
- Real-World Example: Ariana Afghan Airlines Flight 701 Incorrect software modifications can have catastrophic effects. Although not directly caused by software, the principle of correctness in implementation is relevant. In the case of Ariana Afghan Airlines Flight 701, incorrect setting of the altimeter during descent led to the aircraft crashing into a hill. Had there been a software error in a similar critical system, such as altitude calculations, the results could have been just as disastrous.
If you want to dig in details
