Hi All,
There several really great tools for verification and validation of embedded
software for controller models and code (no matter whether handwritten or
auto generated cose). The correctness and stability of controller models can
be verified threough the use of formal methods and test vector generation
and code can be tested and verified through test vector generation, as well.
There are others, but for real-time, safety-critical systems in Aerospace
and Automotive the leading software development tool is "Reactis" from
Reactive Systems. This is a relative easy tool to use and there are well
defined links to Simulink and Stateflow (from The Mathworks).
I'll just stop here.
Mark
----- Original Message -----
From: "Michael A. Newell, WB4HUC" <mnewell1@austin.rr.com>
To: <tentec@contesting.com>
Sent: Tuesday, August 12, 2003 7:35 AM
Subject: Re: [TenTec] Re: Continuing Orion evaluation/Dragonball
>
>
> > > I believe it would be possible to develop a methodology for the Orion
> > > where you could test all possible or likely combinations of buttons,
> knobs,
> > > and menu items, but considering how many ways all those controls
> > > interact, it'd probably take a couple of hours to conduct such a test.
> > <snip a lot>
> > > After each firmware change not only would new or changed features need
> > > to be tested, but all existing functions would have to be tested to be
> sure
> > > none were broken when the firmware was changed.
> >
> > I don't entirely disagree with your assessment since I found problems
with
> my
> > first-day-ship Orion that should have been obvious and caught before the
> radio
> > left the shop.
> >
> > But I think you underestimate the scale of the problem. Since sequence
of
> > control operation matters, the number of tests required to test every
> possible
> > permutation grows as N!. N on the Orion is a sizable number.
> >
> >
> > I've drawn some conclusions about the structure of the software from
it's
> > behavior. I'd love to get my hands on the source code :-)
> >
>
> Well, testing even the most likely combination of buttons, knobs, and menu
> items would be absolutely tedious, time consuming, and extremely boring.
>
> That doesn't mean it shouldn't be done.
>
> If I understand it right, the processor used in the Orion is the same as
the
> one in my PDA. I've done some small amount of PDA programming, and
> it's pretty much event driven. In other words, the software waits for some
> input for the user, then executes the code for that item that was selected
> from the screen.
>
> I would assume (and you know what happens when we assume) that the
> Orion firmware is similar. The software is there, running, waiting for you
> to
> turn a knob, push a button, or select a menu item. Then it executes the
code
> for that selection.
>
> So the code to operate the panoramic stereo receive, for instance, is
> probably
> separate from the code for the CW or SSB filter selection. So some
sections
> of the code probably are isolated from one another and don't interact at
> all. But
> only the person who wrote or maintains the code would know that. The point
> is,
> it might be possible to divide the testing into different areas, depending
> upon
> interaction between sections of the software.
>
> And you're right, there will probably always be some oddball combination
of
> control operation that will do weird things. And every software system
I've
> ever used or worked with has had bugs in it. But to me, the goal for any
> software developer should be to get ALL of the obvious problems squared
> away, then maintain some sort of organized testing effort that will keep
> those
> errors from creeping back in with future updates. Until that happens, the
> owners
> will be the ones to find and report these obvious problems.
>
> Most of the IBM mainframe commercial software systems I've worked with
over
> the past 25 years have run into eight or nine hundred thousand lines of
> source code
> spread across a thousand or more separate programs, and yet we manage to
> modify and test them successfully so that most problems reported by our
> customers
> are of the obscure variety that happen with certain hardware that we may
not
> have in our own shop, or interaction with other software products that we
> can't
> predict ahead of time.
>
> Compared to that, I believe the Orion firmware, running on basically a
> pretty simple
> CPU should be relatively easy to test. Tedious and boring, but easy.
>
> I guess it's all a matter of perspective.
>
> --
> Mike - WB4HUC
> Austin, TX
>
> _______________________________________________
> TenTec mailing list
> TenTec@contesting.com
> http://lists.contesting.com/mailman/listinfo/tentec
>
|