Re: Update on IEC 62304 revision - 4 May 2012
How would/ are you managing legacy code against the requirements of 62304?
Using the SOUP approach has benefits, to be sure. Does that black box do what it needs to? This could be a difficult thing to rationalize if it was the entire product in a Class B or C product. I wouldn't feel comfortable doing that.
The details to make a decision would involve the quality of the software itself (coding approach and standard compliance, internal documentation) and the quality of external documentation (design, arch, requirements). A big plus if there are unit tests for the code.
The issues of verification vs. validation and how you can do either to software without a full system are always present. The first is a symantic battle to get people in the product team and company to agree. I know whats "right" but getting unified thought is tough.
Verifying software without a system is a technical challenge. We're covering 85% of our Class B requirements with an off-line simulation. This is pure software and not a functional simulator. The simulator has been validated. 15% of the requirements need manual tests on the actual product and we want that to show real functionality, too.
The simulated tests eliminate dependencies on misbehaving sensors and intermittent development hardware and allow a pure software test. Of course, we provoke those conditions through the simulation to show the risk mitigations as stated in the DFMECA work.
A lot of work? Not so bad, really, as far cheaper than doing the manual tests repeatedly and far, far cheaper that creating a functional simulation that applies real conditions to the hardware. (E.g., a LabView-based simulator) The ability to cut a release knowing the code works and the test engineer will only needs to document success is a huge benefit to this approach.
And we run 90%+ of our unit and integration tests in the simulator as well. Some things have to be done on the hardware but all the "business logic" can be tested in the simulator.
