Clause 5.1.12 of Technical Standard IEC 62304/A1

BargeSim

Starting to get Involved
Good Morning,

I am currently a little stuck on Clause 5.1.12 of Technical Standard IEC 62304/A1
any help on this clause?

I can not understand what the Standard mean with a "procedure".

Can be enough to manage it through Risk Management and related evidence in the RMF file?

Thanks Everyone.
 

Tidge

Trusted Information Resource
Section 5.1.12 is "Identification and avoidance of common software defects".

The requirement 5.1.12(a) to procedure-lize defect tracking (as part of the development plan) exists primarily so that all defects are identified, classified, and processed according to a common process (no ad hoc approach to identified defects). A medical device software developer may have a common software defect handling process or can establish one within the plan. Software Development Plans have a tendency to 'end' upon design transfer, so I recommend an issue/defect tracking process that can be used for both development and on-market phases.

In my opinion it would not be appropriate to expect that Risk Management activities act as a substitute for software defect tracking (a.k.a. "issue handling") any more than it would be to try to address Corrective Action through Risk Management.

The requirement 5.1.12(b) can be addressed via an interface with RM activities. A common approach is to reference relevant RM file line items within the defect tracker and to reference known defects within the appropriate RM files.
 

BargeSim

Starting to get Involved
Thank you Tidge for your prompt reply.

I thought the point 5.1.12a) was highlighting the adjective "common" referred to the software defect, not to the procedure. But in your opinion I can refer to the "general" issue/defect tracking procedure for this point, too?

Ok for the point b), thanks.
 

yodon

Leader
Super Moderator
My take on it is not issue tracking but how you will avoid defects endemic to the programming technology. For example, memory leaks. You will likely attempt to avoid them through code reviews or maybe there's a tool that automates checking. We point to our coding standards to identify the types of common software defects and then use our code inspection / peer review process to find and eliminate them.
 

Tidge

Trusted Information Resource
Ah, I see the point about 'trying to avoid endemic issues'.

62304 (all flavors) is peculiar in that it supposes to be a process standard but comes dangerously close into wanting to be a product standard(*1) that tells developers how to do in their job. It's my opinion, but I wouldn't waste time trying to establish criteria to tell the difference between 'common' and 'uncommon' defects (for potentially diverse methods of implementation) and establish a specific methodology for only one category (of a given implementation). There is simply too great a variety of 'mistakes' that can be made in any development effort to try focus only on the avoidance. If you look at the referenced table B.2 from TR 800002-1 as some of the examples of 'categories of defects'(*2) there are precious few that would not be uncovered by Testing or Analysis (as always, mileage varies on the robustness of test methods).

That being written, if 5.1.12(a) is all about identifying the defects to avoid it isn't clear to me that 5.1.12(b) brings much value as it presupposes that some of the defects that were 'predicted' might actually be willingly present and intentionally left in the finished product. The point of these two clauses in conjunction may be too subtle for me.

(*1) Some elements of 62304 feel as if this was a standard about the requirements for designing and developing a mechanically fastened object, that certain clauses would divert into specific discussions about driving mechanisms and surface finishes of particular fasteners.

(*2) Locally, we typically utilize multiple levels of test/analysis/inspection for our software (generally this is coded and compiled from text sources). The lowest level is code inspection, and even though we have some routine questions to answer about the code (some specifically appear in TR 800002-1 B.2) so I suppose this 'counts' for the purposes of 5.1.12(a) even though the specific defect types are not called out in a development plan. More likely is the case that the finished product fails a specific test due to a previously unrecognized defect (e.g. a race condition, or an asynchronicity) but in the circumstances I'm familiar with these aren't endemic to the programming methodology. In the interest of full disclosure: my practice has been that when system testing (beyond integration or unit testing) results in a failure due to a specific software defect, in addition to anomaly resolution, I actually do update the RM files to reference the specific failure (often as a potential contributing to a risk item)...but we've always eliminated that anomaly.
 

pmg76

Starting to get Involved
Hi everyone!
I think "yodon" is correct. For me there are two key parts in the phrase 5.1.12.a), "categories of defects" and "programming technology".
Table B.2 in IEC TR 80002-1-2009 lists several software causes that can be considered inherent or intrinsic to a programming technology. So, if you go through this list you will be able to identify which ones apply to your situation (for example, if you use pointers in C or C++ you will face the problem of dealing with "Errant pointers").
For point 5.1.12.b), I'm not sure if the Standard is telling us to document this situations in a Risk Analysis or there is a door to do it some other way?
For example, if I face the problem of "memory-leaks" I could say that dynamic allocation of memory is not allowed. One way of documenting this could be to add a Risk Analysis with a Control Measure indicating this restriction; or I could also not do the risk analysis and add a check in the code review guideline. Are we forced to do the Risk Analysis? How would you document this type of considerations?
 
Top Bottom