Software safty rules

[venki]

Hi!

If we use the Labwindows /CVI to develope the medical applications any
software safy rules or safty standereds ..specified by the national
instrument..?Where i can get the more information regarding this..If
it is not possible,then what are the gendral software safy rules or
standerds i should follow..?
Please guide me..
thanking you.
-venki

[mikeporter]

Rule 1: Software is not safe.
Rule 2: Never forget Rule 1.

The point here is that there are too may variables in the operation of software that are beyond the control of the application developer. Safety systems need to be implemented in hardware so they will be operational if the computer crashes, LabVIEW (oops, I mean LabWindows) crashes, your code gets hung in an infinite loop or what have you.

Beyond this advise, use good software design methodology for the language you are working in and document everything. I hate to think how many problems I have found over the years during the process of describing how the code works...

Mike...

[Ben]

Good post Mike!

re: your last comment,
This is why I train our new developers to describe the code first, then write it.

Ben

[wiebe@CARYA]

Ben,

Describing the code first is how it should be done.

The big question is: how?

Flowcharts, UML, statecharts, whatever. They all seem to be designed for
pure OOP. Have you found a way to do this for LabVIEW? Or, what way do you
like best?

Regards,

Wiebe.


"Ben" wrote in message
news:5065000000050000002ADD0000-1042324653000@exchange.ni.com...
> Good post Mike!
>
> re: your last comment,
> This is why I train our new developers to describe the code first,
> then write it.
>
> Ben

[mikeporter]

Perhaps all the above, perhaps none of them. Trying to find the universal design tool is in my opinion an inherently fruitless task, because everyone's brain works differently.

Far more important than the tool you use is developing the attitude of doing the design--then start stretching wires. However, this process involves far more than simply defining how individual VI's will work... it's also defining an overall architecture for the finished product (including both hardware nad software) that allows you to see how all the parts will fit together, how and when they interact and what different parts of the code have in common.

Mike...

[wiebe@CARYA]

And then there is the phase even before the design.... Getting the user
requirements.

Back to the original question.

We use GAMP. GAMP has FDA approval, and using GAMP can result in validated
software, if used correctly.

Although GAMP seems to be very complete at first, you still need to figure
out all the hard stuff. Things like:
how to get the requirements,
how to write them down in an orderly fashion,
how to make them traceable from the following documents (traceability),
how to do the design,
how to do the testing, etc.

Of cource, there are lots of resources, e.g. at the SEI, IEEE, gamp.org.
Also have a look at CMM, which describes the stages of software maturity.

CMM is very interresting, because it gives advise abo
ut the steps that
should be taken to get to a higher software quality. But be warned, the
advice might take years to fill in, like 'you need a quality system'.

Regards,

Wiebe.



"mikeporter" wrote in message
news:50650000000500000053DD0000-1042324653000@exchange.ni.com...
> Perhaps all the above, perhaps none of them. Trying to find the
> universal design tool is in my opinion an inherently fruitless task,
> because everyone's brain works differently.
>
> Far more important than the tool you use is developing the attitude of
> doing the design--then start stretching wires. However, this process
> involves far more than simply defining how individual VI's will
> work... it's also defining an overall architecture for the finished
> product (including both hardware nad software) that allows you to see
> how all the parts will fit together, how and when they interact and
> what different parts of the code have in common.
>
> Mike...

[Ben]

I will generally start with big fluffy clouds diagrams.

Example

Cloud#1:
DB server and GUI

Cloud#2
Data Acq and hardware control.

Once the customer buys into that, I go for the state transition diagrams starting at a very high level. These diagrams must acount for all the requirements of the app. Again no details, just a lot of "hand waving".

Again I work on getting the customer's OK.

This serves as a line in that sand and help me control scope creep. If it is not addressed in the diagrams, don't expect it!

Then I return to the "hand waving" states and start to nail down exact behaviour. Things like;
What over-rides what, etc....

Again I get a buy off. If the details mean I have to change things, fine! It
is alot easier to mod a state transition diagram than code.


If the application is large, I will then insert an analysis of the data required to drive and control all of the states. This lets me ID where I may have performance issues or conflicts. Shift registers and action engines are then defined.

After this, I can pass the design to any of our developers and the coding can begin.

I admit that I some times miss a shift register value here or there but,
It has been a long time since I had to go back and modify the sequence of states executed in one my state machines.

So, What do y'all think?

Ben

Hoping to turn this into a profitable group think.

[wiebe@CARYA]

Ben,

Sound good. Do you use Visio?

The only (unavoidable) backdraw is that customers always want to know how
much (time and money) it's going to cost before you start. Figuring out the
details might result in hidden extra's. So, there are two choices; doing
lots of specification for free (and if you're done, try telling the customer
he still has to pay for it), or guessing a price and go from there. Getting
customers to pay for the specification is hard. This is of cource something
that cannot be solved with a design method...

I'm using visio to draw my own type of charts. Basically, it is a flowchart,
but with a few modifications. I use buffered state machines, and I adjusted
the flowchart to represent the state buffer.

I've added visio layers. A layer has details about e.g. UI objects. So a
state in the flowchart has an arrow to a square, with the name of the UI
object. This way, an engineer (me) can see easilly which state reads,
writes, or modifies the control or indicator.

I also have a layer for resources, like files, databases, and dynamically
called vi's. Visio allows you to print a selection of layers, so all sorts
of overviews can be created.

What I am looking for is a way to make some rough pictures, like you
describe, and then be able to have a one-on-one graphical like to a more
detailed flowchart. Perhaps also with layers? I don't think it's
possible/practical in standard programs, and designing this kind of software
is hard. For now, I only have some wild ideas about it....

Regards,

Wiebe.



"Ben" wrote in message
news:5065000000050000009ADD0000-1042324653000@exchange.ni.com...
> I will generally start with big fluffy clouds diagrams.
>
> Example
>
> Cloud#1:
> DB server and GUI
>
> Cloud#2
> Data Acq and hardware control.
>
> Once the customer buys into that, I go for the state transition
> diagrams starting at a very high level. These diagrams must acount for
> all the requirements of the app. Again no details, just a lot of "hand
> waving".
>
> Again I work on getting the customer's OK.
>
> This serves as a line in that sand and help me control scope creep. If
> it is not addressed in the diagrams, don't expect it!
>
> Then I return to the "hand waving" states and start to nail down exact
> behaviour. Things like;
> What over-rides what, etc....
>
> Again I get a buy off. If the details mean I have to change things,
> fine! It is alot easier to mod a state transition diagram than code.
>
>
> If the application is large, I will then insert an analysis of the
> data required to drive and control all of the states. This lets me ID
> where I may have performance issues or conflicts. Shift registers and
> action engines are then defined.
>
> After this, I can pass the design to any of our developers and the
> coding can begin.
>
> I admit that I some times miss a shift register value here or there
> but,
> It has been a long time since I had to go back and modify the sequence
> of states executed in one my state machines.
>
> So, What do y'all think?
>
> Ben
>
> Hoping to turn this into a profitable group think.

[Ben]

I have not moved to visio YET.

I started out using paper and pecil.
Then got pretty good with Paint.
These days I have been using PowerPoint.

The end graphics get cut and pasted right into the diagram! In fact one of our Senior Engineers (Marcela X) came up with the idea to put the code in state one one a sequence structure, and the diagrams in seq frame #2. This is the one and only exception to the multi-frame sequnce structure rule that we tolerate.

It is great for those phone calls you get a year latter saying "Ben, my machine just froze up after doing this blah blah blah. Did my data get saved?"

I can look at the state transition diagram for what they observed and give them a solid answer in a ma
tter of seconds!

The ST diagrams if written with LV in mind, translate directly into state machines so I can deliver code to novice customers and they can quickly grasp where what is happening.

Ben