Re: Ada and Automotive Industry

[peb@transcontech.co.uk ("Paul E. Bennett")]

In article <571qub$l1n@mill.gdls.com> schwarza@gdls.com "Art Schwarz" writes:

> GM is switching to C as their main high-level embedded processor language.
> One GM stumbling block (since overcome I believe) is the lack of fixed
> point arithmetic. However, GM has much more fundamental problems to over-
> come than language.
> [1] As a corporation, GM does not understand Systems / Software Architecture
>     and design.
> [2] There are invested prefectures (within GM) which will not move from
>     absolute assembly language.

These first two points it is hard to do something about unless there is a 
corporate will to effect the changes.

> [3] There are managers who do not understand or acknowledge the necessity
>     for a large scale toolset for configuration management, design, and
>     development.

Configuration/Change Management has now got to the stage where it requires 
more than mere manual labour alone can handle. Software tools are becoming 
available for such tasks and they should be looked at by any corporation.

> [4] Ditto for migrating from absolute assembly language to relocatable
>     assembly language to a high level language.

With Forth you could view this as a new macro-assembler and import the 
majority of the assembler if that's their view. Better would be to design 
in Forth from the beginning though.

> [5] GM implementation and test procedures are arcane (at best) and often
>     self-defeating. Rigorous test consists of getting in a car and seeing
>     if anything happens.

I am sure they must have many steps to testing before anyone gets in a car 
with new software.

> [6] The development of requirements suitable for implementation is 
>     overshadowed by the development of requirements which are the 
>     implementation. The result is insufficient attention to requirements 
>     analysis as opposed to implementation (code) inspection.

Does this not cost them in the long run. More requirements analysis up front 
has proved time and time again to be the most valuable investment any company 
can make.

> [7] GM applies 'magic bullet' technology. Given a perceived software 'hole'
>     or significant failure, software tools will be purchased and exper-
>     imentation performed with the tool. Bypassing the problems associated
>     with not having staff with the appropriate knowledge, training, or
>     inclination. (The same applies to the grand acquisition of junior people
>     in targeting disciplines hired to plug a knowledge hole.)

This sounds like fixing the leaks after they happened instead of preventing 
the leaks in the first place (rubber dinghy analogy - don't permit sharp 
knives to be caried).

> [8] A penny saved should be banked. The attention of 'penny pinching' by
>     purchasing and using minimal architecture computers forces development
>     to proceed into extraordinary pot-holes.

It's no use trying to save penny's at the end of a project if you spent too 
many pounds at the start.
 
> There is no true feel for the art and practice of software in the auto
> industry in general (not just GM). This results in a continuously and
> replayable suboptimal development behavior. Although I cynically say
> that no auto manufacturer is happy without a ball-peen hammer in hand,
> I think it more appropriate to say that the in-built inertia in the
> largest company in the world precludes the replacement and / or education
> of the company doers. The auto manufacturers are conservative in just
> the arena where conservatism has no voice - software and firmware. I must
> say that this is ironic. GM (in the very early 60's) was one of the prime
> developers and one of the first users of graphics devices (Lockheed was
> the other one).
> 
> To recognize change requires insight. To insist on it requires courage.
 
You could be right. Industries like GM would seem to need to wake up a 
little, there are plenty of small companies who, given the opening to produce 
cars that people would like, would probably take it.

-- 
Paul E. Bennett <peb@transcontech.co.uk>
Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely