IEC 62304 compliant Architecture definition

Question

I am currently tasked with creating a software architecture for compliance with IEC 62304. These regulations are notoriously vague, and do not provide any real substance as to what is required for a "software architecture". The standard states

The manufacturer shall transform the requirements for the medical device software into a documented architecture that describes the software's structure and identifies software items.

Now I went to an applied computer science school, so the vast majority of my teachings were around how to actually write code and working on projects, so as far as I can remember, we never covered anything involving creating software architecture diagrams.

I've already basically written all of the software, but for regulatory submission purposes I need to create this documentation for the project.

So in short my question is this: What exactly does a "software architecture" consist of?

Answer 1

We're going though the 62304 learning curve right now.

As the previous answer suggests it is just the high-level view of your medical device software.

According to the standard you should at minimum list the various modules/components. Components are defined as being made of software items. However, how you define components and items is entirely up to you.

In our case, products often have one component and rarely more than three.

In the case of a engineer-workstation-based GUI project, we have four component. The GUI, the product logic, and an existing DLL we are required to integrate, and the underlying mathematical modelling engine that the whole system is based upon.

The architecture consists of

1. description of the GUI,
   • basically a list of screens and their associated workflow
   • a description of the objects(software items) associated with each screen
2. a description of the product logic
   • a description of the state machine, and how it interacts with the GUI workflow
   • a description of the state machine class (a software item)
   • a description of the mathematical-modelling operations being performed for the client. (broken down into stages - each stage is a software item)
3. a description of a required DLL, its SOUP status, etc. (one software item)
4. a reference to another software component developed under 62304

One thing to bear in mind is that (despite the heavy implication of the way the 62304 standard is written) you don't have to create the architecture diagram up front and then fix it in stone in a waterfall coding model. The FDA have encouraged the use of more agile approaches, allowing you to develop the architecture along with the code, so long as your validate the final architecture against the final design. So start with a simple architecture that allows you to make progress, and keep it up to date as you develop the code. See the AAMI's TIR45 publication for some documented justification.

Answer 2

Software Architecture looking at the software from a high level. This will focus on how different software components interact with each other. It also consists of how outside systems can interact with your software system, or if you even allow outside systems to interact. If you think of how a building architect does by designing a building, a software architect will design a software system. This involves documenting the software system. Some examples of how to document would be to create a requirements document, use case document, class diagram, state diagram, interaction diagram, help files to name a few.

As far as how much detail to use, I would say you will want to use enough to effectively portray what the system is supposed to do and what different messages mean when the system is not doing what the client is trying to do. They will need help documents and a glossary of terms, specially error messages.

For your team, I would use the requirements and other various documents to specify how the system works. This will help greatly with maintenance and enhancements. The requirements will help guide the team to determined when you have a finished, working product.

Answer 3

The standard is vague. But the expectation is that your QMS processes will be structured to define how your organization uses those documents. You define the requirements for the document, how those documents will be used and maintained. To reenforce that point, the Paperwork Reduction Act (PRA) of 1995 is to ensure that Federal agencies, including the FDA, do not overburden the public with federally sponsored information collections; the information required serves a useful purpose. The FDA has very general goals, but if the architecture document contents don't serve a real purpose it is not required.

So a software architecture document (IMHO) must serve a set of requirements in a project. The general needs of the FDA may be met, I think, if the document:

1. Communicates a useful ideal of the scope of a design to a reviewer, or new worker familiarizing themselves with the product.
2. Defines independent functional blocks within the design. Independent both in the sense of independently specified, designed, and, tested components of the design.
3. Identifies testable interfaces to each component in the design.
4. Defines consistent terminology that is used in the project to refer to the components of the design.

The architecture document should be a primary reference when the project subdivided the work and should be reflected in the cognizant engineering skills of leads in the group, sections of the documentation, and how V&V is approached.

This is not a requirements document, though. It should give a context and vocabulary for the pieces and the processes in the box, but the requirements document should provide the meat for the functions and the testing required.