Diskussion:ASCET

?

-- Die Software wird nicht Klassifiziert noch sonst in einen Kontext gesetzt.
-- Es wird nicht beschrieben, welche Eigenschaften ASCET eigentlich hat.
-- Es wird nicht beschrieben, welche Fähigkeiten die Software nicht hat.
-- Viele Aussagen treffen auf jede Software zu, die in diesem Bereich eingesetzt wird
-- Praktisch alle Links führen zu sind ETAS Seiten, es gibt keine neutrale Beurteilung
-- Statt zu konkreten Statistiken oder Tabellen führen die Referenzen zu ETAS "Broschürensammlungen"

-- Viele Formulierungen sind schwammig und plakativ: (Version vom 8.Nov.2007, 11:00)

"...sämtlicher namhafter Automobilhersteller und deren Zulieferer..."
=> Der wird der Eindruck erweckt, ein Hersteller müsse Ascet verwenden, um Namenhaft zu sein.
=> Wann ist ein Automobilhersteller namhaft? Gilt das wirklich auch außerhalb Deutschlands oder Europas?

"...Diese Steuergeräte sind im Fahrzeug dann später verantwortlich für Funktionen..."
=> Keine Aussage zu der Software ASCET, dass könnte man auch alles "Hart in C" coden!

"Seine hauptsächliche Anwendung findet ASCET in den Bereichen"
=> Es wird der Eindruck erweckt, nur ASCET würde diese Bereiche beherrschen: Dieses sind Bereiche in denen Simulationsamodelle und Blockschaltbilder allgemein eingesetzt werden. Darin wird dann selbstverständlich auch ASCET verwendet.

"erster automotiver Codegenerator"
=> "automotiv" ist kein informatischer Fachbegriff, ASCET wurde auch nicht als erster Codegenerator in der Automobil Branche verwendet
=> es gibt noch eine Reihe weiterer möglicher und wichtiger Zertifizierungen, auf die nicht näher eingegangen wird.

"Die Stückzahlen der mittels automatischer Seriencodegenerierung erstellten Steuergeräte "
=> Bezieht sich auf automatische Seriencodegenerierung, diese muss nicht mit ASCET gemacht worden sein
=> Bezieht sich auf Stückzahlen von Steuergeräte, die Kausal gar nichts mehr mit den Entwicklungsumgebungen zu tun hat. Luft- und Raumfahrtsoftware z.B. ist hochqualitativ und wird nur in sehr kleiner Stückzahl produziert!

"...muss ASCET aufgrund seiner Verbreitung als industrieller de-facto-Standard angesehen werden."
=> Wir MÜSSEN hier gar nix!
=> de facto bedeutet "nach TATSACHEN", nach welchen Tatsachen? Marktanteile? Verbreitung? Belege? Wer, außer dem Hersteller, behauptet das?
=> Die Aussage könnte bei schnellem Lesen auf alle Einsatzbereiche interpretiert werden, dabei ist nicht mal belegt ob sie für die beiden genannten gilt.

Persönliches Fazit: Der Artikel ist WERBUNG von der ETAS, und auch noch eine schlechte, da sie nichts über die Produktmerkmale aussagt. --Ralf1980 23:56, 9. Nov. 2007 (CET)

---

Kurze Stellungnahme zu deiner Kritik:

• Der wird der Eindruck erweckt, ein Hersteller müsse Ascet verwenden, um Namenhaft zu sein.

Nein, rein von der Sprachlogik wird das hier m.E. nicht angedeutet. Aber die Formulierung wurde ja schon abgeschwächt.

• "...Diese Steuergeräte sind im Fahrzeug..."

Für fachfremde Leser ist es trotzdem gut, hier eine kurze Zusammenfassung zu sehen, was für Steuergeräte mit Hilfe von ASCET entwickelt werden. Für die gegebenen Beispiele gibt es tatsächlich entsprechende Projekte. Auch hier wird m.E. nicht behauptet, dass man Scheibenwischersteuergeräte nur mit ASCET entwickeln kann :-)

• Es wird der Eindruck erweckt, nur ASCET würde diese Bereiche beherrschen

Im Gegenteil, hier wird eher der Funktionsumfang von ASCET eingeschränkt im Vergleich zu anderen Tools. Eine Behauptung, dass nur ASCET dafür geeignet ist, sehe ich hier nirgends.

• "automotiv" ist kein informatischer Fachbegriff, ASCET wurde auch nicht als erster Codegenerator in der Automobil Branche verwendet

informatisch ist auch kein Fachbegriff ;-). Aber danke für den Hinweis, ich habe die Formulierung geändert. "erster Codegenerator" bezieht sich nicht darauf, dass ASCET den ersten Codegenerator überhaupt enthält, sondern dass dieser Codegenerator als erstes zertifiziert wurde.

• Bezieht sich auf automatische Seriencodegenerierung, diese muss nicht mit ASCET gemacht worden sein

Habe ich eindeutiger formuliert.

• Wir MÜSSEN hier gar nix!

Natürlich nicht :-). Das kann man sicher besser formulieren. Vorschläge?

Ansonsten gilt natürlich: Bring deine konstruktiven Verbesserungsvorschläge hier ein und helfe mit, dass der Artikel besser wird. Sei mutig!

- ChristianR

Mutigkeit

Hi Christian, in der überarbeiteten Fassung gefällt er mir der Artikel schon besser. Ich wollte ihn aus dem einfachen Grund nicht verbessern, da ich mich nicht tief genug in der Materie beziehungsweise gar nicht in ASCET auskenne. Das war ja der Grund, warum es mich überhaupt hierhin verschlagen hat. Ich habe zwar schon von ASCET gehört und die Oberfläche mal gesehen, aber weiß zu wenig darüber, um gute Aussagen treffen zu können. Aber halt genug, um ein wenig Kritik üben zu können. Warst du vom Fach oder die Person / Personen hinter der anderen IP? Gruß, Ralf --Ralf1980 00:45, 13. Nov. 2007 (CET)

Neutralität

Neutralität scheint mir dem Artikel leider nicht zugrunde zu liegen. Die Gründe sind folgende:

• allgemeine Werbeformulierungen wie Unterstützung aller relevanten Standards gehörten selbst dann nicht in einen enzyklopädischen Artikel, wenn sie wahr wären. Im Falle von ASCET muss ich da zusätzlich noch anmerken, dass:

- das von ASCET verwendete Echtzeitbetriebssystem ERCOSEK nicht OSEK-konform ist

ASCET hat bereits seit den 4er-Versionen (also Anfang des Jahrzehnts) neben ERCOSEK weitere RTOS unterstützt (Stichwort OSEK OIL). Außerdem ist ERCOSEK 4.3 durchaus OSEK-konform, was auch die OSEK/VDX-Zertifizierung 2003 bestätigte. Des weiteren unterstützt, wie weiter unten bereits von ChiefController angeführt, ASCET seit einigen Jahren RTA-OSEK, welches definitiv ebenfalls OSEK-konform ist. Bitte informieren, bevor Du zur Tat schreitest. --Durchzug 17:45, 6. Apr. 2008 (CEST)

- XML kein relevanter Standard für einen Production-Code-Generator ist

Stimmt. Stand aber auch nirgendwo. Dass XML aber ein durchaus relevanter Standard für in der Automobilindustrie eingesetzte Softwarewerkzeuge ist, möchtest Du nicht bestreiten, oder? --Durchzug 17:45, 6. Apr. 2008 (CEST)

- Die von ASCET generierten a2l-Dateien (ASAM MCD 2MD) sind nicht Standardkonform und können deshalb nur vom ebenfalls von ETAS stammenden INCA gelesen werden, nicht aber von firmenfremdem Kalibrieprodukten wie CANape (Vector Informatik) oder CalDesk (dSpace).

Ich habe selten einen schlechter formulierten und weiter auslegbaren Datenformatstandard als ASAP2 gesehen. Daher kann ich es keinem übelnehmen, wenn seine eigene Interpretation nicht der aller anderen Tools auf dieser Welt entspricht. Nichtsdestrotrotz hat sich in dem Umfeld einiges getan, ist bei weitem nicht mehr so schlimm wie früher. Und dass INCA von ASCET stammende a2l's lesen kann, hat nicht etwa was mit ASCET oder proprietär zu tun: INCA frisst so gut wie alles ;-) --Durchzug 17:45, 6. Apr. 2008 (CEST)

- Der von ASCET generierte C-Code ist in mehreren Aspekten NICHT Misra-C-konform. Misra-C ist zudem weitgehend irrelevant, da Misra-C-Regeln speziell für händisch geschriebenen Code entworfen wurden, nicht für generierten. Viele Regeln z.B. zu Makros oder Verwendung von Globals sind für generierten Code blanker Unsinn.

Abschnitt "5.4 Claiming compliance" des MISRA-Standarddokuments beschreibt, unter welchen Umständen sich ein Produkt als MISRA-C compliant bezeichnen darf. Hier steht nichts davon, dass 100% aller Regeln erfüllt sein müssen, sondern im wesentlichen, dass eine Compliance-Matrix geführt und alle Regeln mit Abweichungen dokumentiert sein müssen. Dies ist für ASCET der Fall, weshalb die Bezeichnung von ASCET als MISRA-konform völlig in Ordnung geht. Deiner Anmerkung zu händischem Code stimme ich prinzipiell völlig zu, was jedoch nichts daran ändert, dass bei Automobilfirmen, die Codegeneratoren einsetzen, immer häufiger die Einhaltung des MISRA-Standards gefordert wird. Daher ist der Standard alles andere als irrelevant, auch wenn sehr wohl über die Sinnhaftigkeit diskutiert werden kann. --Durchzug 17:45, 6. Apr. 2008 (CEST)

• Die Quellen sind sehr unbefriedigend: Von den 8 angegebenen Quellen sind 4 Links auf ETAS-Seiten (Homepage oder Firmengazette), eins ist tot, 2 verweisen auf Dokumente auf den Seiten von Privatpersonen. Der letzte Link verweist auf eine IEEE-Seite, die die Zusammenfassung eines Artikels der Firma Bosch enthält. Bosch wiederum ist Besitzer von ETAS. Inhaltlich läßt sich nur ersehen, dass 1994 ASCET von Bosch in einem Projekt zur Simulation verwendet wurde, was die Aussage "Die Automobilbranche setzt ASCET seit den frühen 90ern in der Serienentwicklung ein" nicht belegt, denn Bosch ist nicht die Automobilbranche sondern der Mutterkonzern von ETAS.

Die Qualität der Quellen ist in der Tat nicht berauschend. Was aber auch daran liegen dürfte, dass in einer eher geschlossenen Branche wie der Automobilindustrie selten öffentlich und gleichzeitig noch schriftlich und verlinkbar kommuniziert oder zitiert wird. Jede Unterstützung, weitere und bessere Quellen zu ist sicherlich willkommen. Was den Hinweis auf die Privatpersonen betrifft: Es geht um veröffentlichte Artikel zum einen in der Automotive Electronics, zum anderen auf der SEAS 2005, die dort runtergeladen werden können. Es geht mitnichten um Aussagen von Privatpersonen, wie man Deinen Hinweis auch verstehen könnte. --Durchzug 17:45, 6. Apr. 2008 (CEST)

• die Behauptung, ASCET sei "de-facto-Standard" ist ein schlechter Witz. Die meisten Beispiele stammen von BMW. Eben dort wurde 2004 in der Vorentwicklung eine Evaluierung von Seriencodegeneratoren vorgenommen, an dem ASCET zunächst aufgrund zahlreicher Mängel wie fehlendem Config-Management, katastrophaler Verwaltung der eigenen Programmversionen und fehlender Kompatibilität zu Standards (s.o.) gar nicht erst teilnehmen sollte. Nach längerem Gejammer des ETAS-Residents durfte ASCET dann doch zusammen mit SCADE, TargetLink und EmbeddedCoder antreten und landete auf dem letzten Platz. Inzwischen soll sich die Qualität etwas gebessert haben, Marktführer sind aber EmbeddedCoder und TargetLink, und ASCET ist ganz bestimmt kein Standard. Käptn Weltall 23:34, 28. Feb. 2008 (CET)

Du solltest vermeiden, einzelne Begriffe aus dem Zusammenhang zu reissen und dann hier als Totschlagargument ins Lächerliche zu ziehen. Der Originalsatz war: "Gerade in den Bereichen Motormanagement und Fahrdynamik kann ASCET als Seriencodegenerator aufgrund seiner Verbreitung als industrieller de-facto-Standard angesehen werden." Während sich dSPACE Anfang 2007 selbst damit gefeiert hat, dass eine Million Steuergeräte mit TargetLink-generiertem Inhalt auf der Strasse rumfahren, waren dies bei ASCET bereits damals 50 Millionen. Faktor 50. Und EmbeddedCoder hängt in der Durchdringung weit hinter TargetLink zurück ... --Durchzug 18:21, 6. Apr. 2008 (CEST)

Ich habe erstmal die unbelegten und falschen Aussagen rausgenommen. Was mir nur zweifelhaft erschien, ist noch in html-Kommentaren mit Anmerkung enthalten. Korrekturen habe ich auch bei der Beschreibung der Anwendung vorgenommen, da Ascet dort wo ich selbst beteiligt war (BMW, Audi, Hella) eigentlich immer nur zur Serien-Implementierung verwendet wurde, aber nie zur Funktions- oder Algorithmen-Entwicklung. Dort wurden andere Werkzeuge wie Simulink verwendet, und die so entwickelten Funktionen und Modelle dann händisch (!) für die Serie nach Ascet übertragen. Für Weiterentwicklungen wurden die Ascet-Modelle dann, wiederum händisch, in das ursprüngliche Werkzeug zurückgeführt. Dies war auch der Grund, warum viele Automobilhersteller den Einsatz von Simulink-basierten Seriencode-Generatoren angestrebt haben, weshalb mir die Behauptung bezüglich Marktführerschaft von Ascet eher abwegig erscheint.

Dies ist zwar ein möglicher Entwicklungsprozess, aber weder elegant noch repräsentativ. Vor diesem Hintergrund erscheinen mir die vorgenommenen Anpassungen als recht einseitig. Wie Du selbst geschrieben hast: Du kennst lediglich einen doch recht überschaubaren Ausschnitt ... --Durchzug 18:21, 6. Apr. 2008 (CEST)

Ein Kapitel Kritik an Ascet wäre auch schön, als Gegenüberstellung zu den hier beschriebenen und durchaus vorhandenen Vorzügen von Ascet. Ich habe hier in der Diskussion einige Kritikpunkte angesprochen, die ich allerdings nicht mit Quellen belegen kann, da sie auf persönlicher Beteiligung in der automobilen Vorentwicklung beruhen. Ich werde mich selber mal umsehen und denke, dass hier für Vorzüge wie Nachteile neutrale Quellen (Also weder von Etas/Bosch, noch von der Konkurrenz wie Vector, Mathworks, dSpace, ElektroBit) sehr von Vorteil wären. Wer also was findet, zögere nicht ... Käptn Weltall 00:53, 29. Feb. 2008 (CET)

Nunja, einerseits kritisierst du unbelegte Behauptungen, baust aber eine extrem POV-lastigen Abschnitt (Entwicklung von Ascet und der Etas-Toolkette) ein, der wohl aus deinen Erfahrungen bei BMW bis 2004 resultiert. Ich habe den jetzt mal auskommentiert, weil er - wie erwähnt - viel POV enthält und zudem noch teilweise sachlich falsch ist, z.B. wird schon seit längerer neben ERCOSEK auch RTA-OSEK unterstützt (und auch bevorzugt). Letzteres ist durchaus standardkonform. Auch die fehlende Anbindung an Simulink und Konsorten ist schon längst Geschichte ([1]). Das ASCET nicht 100%ig-Misra-C konform ist, wird von ETAS auch selbst nicht bestritten, weil es keinen Sinn macht. Ich habe das nun auch entsprechend formuliert. Und mit dem Ausplaudern von BMW/ETAS-Interna in diesem Abschnitt bewegst du dich darüberhinaus auf sehr dünnem Eis ... -- ChiefController 11:56, 29. Feb. 2008 (CET)

Sicher POV-lastig, und damit zurecht raus, bis Belege von neutraler Seite dafür da sind. Die unverfroren verlogene Eigendarstellung der Firma ETAS ist aber nunmal extrem ärgerlich, selbst über das normale Mass von Verkäufern hinaus, und der Ärger darüber hat mich veranlasst, hier voreilig eine unbelegte Gegendarstellung vorzunehmen.

Ich muss ChiefController leider zustimmen: Zum einen sind Deine Änderungen und Anmerkungen weder neutral noch aktuell, zum anderen in Teilen schlicht und einfach nicht zutreffend (siehe oben). Bevor Du da anderen Lügen unterstellst, solltest Du Dir vielleicht selbst an die eigene Nase fassen. --Durchzug 18:21, 6. Apr. 2008 (CEST)

Was die Kompatibilität zu Simulink angeht, so war hier schon immer eine automatische Konvertierung in beide Richtungen gefragt, die aus dem verlinkten Artikel nicht hervorgeht. Hier wird lediglich die Möglichkeit vorgestellt, sowohl für Simulink- als auch ASCET-Modelle einen Schnittstellenabgleich gegen ein UML-Architekturmodelle vorzunehmen. Damit werden keine Inhalte übersetzt. In den Broschüren von Etas existiert die automatische Konvertierung von und zu Simulink schon seit 2001, leider jahrelang ohne realen Hintergrund.

Die automatische Modellkonvertierung war zu der Zeit keineswegs Bestandteil von ETAS-Werbematerial. Was ASCET seit vielen Jahren unterstützt, ist zum einen die Cosimulation mit Simulink und zum anderen der Import von C-Code von Simulink nach ASCET. In der anderen Richtung ging das noch nie. Und das im Artikel referenzierte Produkt M2M von aquintos gleicht nicht nur Schnittstellen ab sondern übersetzt sehr wohl Modellinhalte ineinander. Von Simulink nach ASCET, von ASCET nach Simulink. Genau das, was seit vielen Jahren gefordert wurde. --Durchzug 18:21, 6. Apr. 2008 (CEST)

Bezüglich RTA-OSEK bliebe noch die Frage offen, inwiefern es in ASCET integriert ist, also durch den RTOS-Konfigurator unterstützt wird. Denn dass ein OSEK-konformes Betriebssystem angeboten wird, heisst nicht, dass ASCET auch konform ist (->OIL-config). Etas ist schon nicht davor zurückgeschreckt, ERCOS in ERCOSEK umzubenennen, um falsche Tatsachen vorzutäuschen. Hier wäre eine Nachweis von ausserhalb des Etas-Kosmos gefragt.

RTA-OSEK ist auf einer vergleichbaren Ebene wie ERCOSEK eingebunden, inklusive Konfigurator. Und ERCOSEK ist seit Version 4.3 höchstoffiziell OSEK/VDX-zertifiziert. --Durchzug 18:21, 6. Apr. 2008 (CEST)

Recht beliebige Aussagen wie entspricht soweit möglich dem Standard, zudem noch unter Berufung auf die Firmenpostille, sind wohl eher Eigenwerbung von Etas. Deshalb habe ich die Aussage präzieser gemacht. Käptn Weltall 16:48, 29. Feb. 2008 (CET)

Hier prallen halt zwei Welten aufeinander. Einerseits der Ursprungsartikel, vom ASCET-Projektleiter verfasst und natürlich ziemlich euphorisch und andererseits du als (frustierter?) Anwender, der aber wohl schon seit Jahren die Weiterentwicklung des Tools nicht mehr mitverfolgt hat (liege ich da richtig?). Man müsste ein distanziertes Mittelding finden. Ich möchte das aus Befangenheit nicht machen, bin mir aber auch nicht sicher, ob du der richtige dazu bist, da deine Edits doch eine eher negative Grundhaltung an den Tag legen. Wer meldet sich freiwillig? -- ChiefController 12:37, 1. Mär. 2008 (CET)

Indirekt, über Kollegen, habe ich die Entwicklung von Ascet schon noch mitbekommen, Aufträge, die die Arbeit mit Ascet einchlossen, aber grundsätzlich abgelehnt. Eine negative Grundhaltung kommt vor allem dadurch Zustande, dass Etas für meine Begriffe eine beispiellose Skrupellosigkeit an den Tag legt, wenn Aussagen zu den Fähigkeiten seiner Tools gefragt sind. Ganz unabhängig davon sollten aber Aussagen zu Software-Produkten nicht nur durch Quellen des Herstellers belegt werden, insbesondere bei diesem Artikel wo auch schon andere vor mir den halbseidenen Werbecharakter der Aussagen zu Ascet bemerkt und moniert haben (Ralf1980). An dem Artikel können geren andere weiterarbeiten, solange nicht wieder Schleichwerbung untergeschoben wird. Käptn Weltall 22:42, 3. Mär. 2008 (CET)

Boschtochter

Etas ist Boschtochter und das ist für Ascet relevant, weil Bosch der größte Elektronik-Zulieferer der deutschen Automobil-Industrie ist, und damit der größte potentielle Kunde der eigenen Tochter. Wenn hier anonym (als IP) das mit wechselnden Begründungen (erst: stimmt garnicht; nach dem Beweis des Gegenteils: Ist aber nicht relevant) unterschlagen werden soll, spricht das wohl schon für sich und die Motivation der anonymen Autoren. Sollte hier weiter anonym rumgebastelt werden, würde ich eine Teilsperrung vorschlagen. Käptn Weltall 17:22, 22. Mär. 2008 (CET)

Den Hinweis auf die Bosch-Zugehörigkeit habe ich in den Artikel zur Firma ETAS verschoben, welcher hier wiederholt referenziert wird. Dort ist der Hinweis besser aufgehoben. --Durchzug 16:17, 14. Jun. 2008 (CEST)

Nochmals Neutralität (Mai 2011)

Der Artikel hat den Charakter eines Werbeartikels. Er enthält zahlreiche Quellen, aber diese haben ebenfalls Werbecharakter. Der enzyklopädischen Anspruch ist noch tiefer gesunken dadurch, dass kürzlich auch noch die Links auf vergleichbare Produkte anderer Hersteller entfernt wurden.--Inschenör 17:34, 1. Mai 2011 (CEST)

Kritische Punkte wurden entschärft, die gesetzte Neutralitätswarnung habe ich wieder entfernt. Was noch bleibt, ist eine Unausgewogenheit bei den Quellen, hier wären unabhängige Angaben, die nicht vom Hersteller stammen gut. Der Artikel hat immer noch einen gewissen Werbecharakter, ist aber sachlich nun korrekt.--Inschenör 22:10, 18. Mai 2011 (CEST)