Xilinx Evaluation IP is owned and controlled by Xilinx and must be used
5
solely for design, simulation, implementation and creation of design files
6
limited to Xilinx devices or technologies.
7
8
Use with non-Xilinx devices or technologies is expressly prohibited and
9
immediately terminates your license.
10
11
Xilinx products are not intended for use in life support appliances,
12
devices, or systems. Use in such applications are expressly prohibited.
Interessant ist der letzte Punkt. Ich frage mich ob das nur
Einschränkung dieser Lizenz oder gilt das generell für ihre Produkte.
Kennt ihr andere Hersteller, die das so explizit ausschliessen?
Andere Hersteller: Intel, AMD, - nahezu jeder CPU-Hersteller.
Das Problem bei allen software-basierenden Systemen liegt darin, daß
Tests ausschließlich die Anwesenheit_ _einzelner Fehler zeigen können,
aber nicht die Abwesenheit_ _aller Fehler.
Das ist übrigens genau das Problem der Wahlcomputer - bitte jetzt
keine Diskussion über diese Geräte!
Bernhard
Z.B. mußt du bei der Musterbestellung von uCs bei diversen Herstellern
(TI, National Semiconductor, Maxim...) auch bestätigen, dass die Dinger
nicht in medizinische Geräte oder in der Luftfahrt eingesetzt werden.
Und bei Software (was einem IP-Core relativ nahe kommt)...
Bleibt bloß zu hoffen, dass Microsoft auch sowas in seinen AGB zu
Windows drin hat.
Ich weiß nicht obs Altera oder XIlinx war, zumindest hab ich beim
Download des Webpacks bestätigen müssen die Software nicht für die
Entwicklung einer Steuerung für RAKETEN / Missiles einzusetzen ;)
@Bernhard
>Das Problem bei allen software-basierenden Systemen liegt darin, daß>Tests ausschließlich die Anwesenheit_ _einzelner Fehler zeigen können,>aber nicht die Abwesenheit_ _aller Fehler.
Bei Software ist das klar. Welche (C,FPGA) Compiler sind schon
validiert.
Oder ist die Überlegung hier: Ich habe meine HW mit Hilfe von SW
entwickelt.
Da SW nicht validiert ist, ist HW möglicherweise fehlerbehaftet.
Beliefern denn diese nicht das Militär? Oder ist dem Militär das egal?
Ich glaub doch, dass FPGA's in Satelliten etc eingesetzt werden. Dh die
Dienste, die sich darauf stützen, sind vielleicht auch aus der Kategorie
Life-Support.
Es stellt sich dann sogleich die Frage, was steckt denn dann in all den
medizinischen Geräten? Und wer fertigt diese?
> was steckt denn dann in all den medizinischen Geräten?
Wie in allen sicherheitstechnischen Schaltgeräten: Redundanz.
Es ist einen Frage der Wahrscheinlichkeit:
Nicht jeder Softwarehersteller und jeder Chiphersteller und jeder
Programmierer kann die selben Fehler machen.
Und speziell in der Medizintechnik: sterben werden wir alle mal.
Warum nicht gerade, wenns uns mal dreckig geht, und wir an so ein Gerät
angeschlossen sind? Wer wird da schon vermuten, dass das Gerät
abgeflippt hat?
Dachte die wuerden einem eben Bauteile FUER solche Anwendungen
verkaufen, aber entsprechend sorgfaeltiger geprueft, teurer und trotzdem
zum Einsatz auf Risiko des Integrators?
@Lothar
Redundanz löst natürlich technische Probleme^^
Juristisch wird man dagegen es schwer haben, zu begründen, warum
man 3 Xilinx Bausteine im life support Applikation eingebaut hat,
wenn der Einsatz von schon einem Baustein verboten ist.
Vom Hörensagen kenne ich auch, dass C und C++ aus sicherheitsrelevanten
Bereichen verbahnt sind. Da soll Ada gefragt sein, aber auch hier läuft
es nicht ohne Pannen: Stichwort Ariane,Ada,Absturz.
Triple A :)
Sind die Hersteller da nicht in der Klemme?
Einerseits winken grosse Gewinne, wenn ihre Bauteile monopolistisch
in med. Geräte verbaut werden, andereseits befürchten sie wohl
Klagen und Imageverlust.
das läuft anders:
Xilinx (und alle anderen Hersteller) "verbieten" erst einmal die
Anwendung ihrer (programmierbaren) Bausteine in "lebenswichtigen"
Anwendungen, um juristisch auf der sicheren Seite zu sein.
Da die Anwender um die Bausteine nicht herumkommen (da das alle
so machen), setzt man sich dann also mit dem jew. Hersteller zusammen
und bespricht, welche Quality-Maßnahmen zu treffen sind, damit der
ANWENDER die Verantwortung übernehmen kann...
Vor langen langen Jahren - ca. Anfang bis Mitte der 1970er - erschien
eine erste Presse zur Blechverarbeitung, die software-gesteuert war. Der
TÜV ließ sich mühsamst vom Konzept dieser Software überzeugen:
- 3 verschiedene Processor-Architekturen,
- 3 verschiedene Betriebssysteme,
- 3 verschiedene Toolchains zur Software-Entwicklung,
- und last but not least 3 verschiedene Entwicklerteams, die alle nach
derselben Spezifikation arbeiteten.
Arbiter, Not-Aus und "2-Hand-Bedienungs-Erkennung" waren noch in
Hardware realisiert.
Heute dagegen werden selbst atomar bestückte Kriegsschiffe mit normalen
Windows-PCs betrieben und hängen am Internet. Es ist ja billiger...
Bernhard
Martin schrieb:
> Vom Hörensagen kenne ich auch, dass C und C++ aus sicherheitsrelevanten> Bereichen verbahnt sind.
Die Relevanz von C und C++ ist derartig groß, dass man sich diesen
Sprachen nicht generell verschließen kann. Daher hat man versucht,
bestimmten Eigenarten dieser Sprachen durch Coding Guidelines zu
begegnen. Stichwort: MISRA-C. Keine Sprache kann Programmierfehler
grundsätzlich verhindern.
Darüber hinaus gibt es keine "verbotenen" Bausteine. Man muss nur
nachweisen, dass die Wahrscheinlichkeit des Auftretens eines
"gefährlichen" Fehlers "ausreichend" gering ist, bzw. dass dieses
Auftreten innerhalb einer gewissen Maximalzeit entdeckt und darauf
geeignet reagiert wird.
Gruß
Marcus
http://www.doulos.com/
Thread beobachten
Seitenaufteilung abschalten