Connect with us

Künstliche Intelligenz

Globalfoundries will CPU-Urgestein MIPS Technologies übernehmen


Beim CPU-Designer MIPS Technologies bahnt sich eine weitere Übernahme an. Der Chipauftragsfertiger Globalfoundries will MIPS übernehmen – beide Firmen haben sich bereits auf die Formalitäten geeinigt. Zu den finanziellen Details schweigen sie sich aus. Noch bis zum Jahresende soll die Übernahme abgeschlossen sein.

MIPS wurde ursprünglich im Jahr 1984 als MIPS Computer Systems gegründet und spezialisierte sich auf die Entwicklung der eigenen CPU-Befehlssatzarchitektur Microprocessor Without Interlocked Pipeline Stages. Dabei handelte es sich bereits um eine RISC-Architektur (Reduced Instruction Set Computer).

Mittlerweile ist MIPS allerdings auf die Entwicklung von CPU-Kernen mit dem offenen Befehlssatz RISC-V und von KI-Rechenwerken umgeschwenkt. Dazu gehören Designs für Fahrzeuge (Automotive) und Edge-Systeme.

Globalfoundries will MIPS als eigenständige Firma weiterführen. Das zugewonnene geistige Eigentum (Intellectual Property, IP) soll das Herstellerportfolio erweitern. Globalfoundries dürfte kommende Designs stark an die eigenen Fertigungsprozesse anpassen, um Kunden mit anpassbaren Chips anzulocken. Die Firma stellt dann nicht nur die Chips her, sondern hilft auch beim Entwurf.

Die Übernahme dürfte derweil nicht allzu teuer sein. Im Jahr 2013 übernahm der britische GPU-Entwickler Imagination Technologies MIPS für 100 Millionen US-Dollar. Nachdem der Investor Canyon Bridge Capital Partners die Firma Imagination 2017 übernommen hatte, ging MIPS an Tallwood Venture Capital. 2018 übernahm das KI-Start-up Wave Computing MIPS. Im Rahmen von dessen Insolvenz wurde MIPS wieder als eigenständige Firma ausgegliedert.


(mma)



Source link

Weiterlesen
Kommentar schreiben

Leave a Reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Künstliche Intelligenz

Drohnenzeugnisse: KI beaufsichtigt theoretische Online-Prüfungen


Das Luftfahrt-Bundesamt (LBA) hat im Juni ein Prüfverfahren genehmigt, das die Beaufsichtigung von Online-Prüfungen (Online proctored exams – OPE) für Drohnenpiloten, etwa das Fernpiloten-Zeugnis A2, durch eine Künstliche Intelligenz (KI) erlaubt. Während der Prüfung ist keine menschliche Aufsicht anwesend. Das Verfahren wurde vom LBA und dem professionellen Drohnendienstleister Droniq entwickelt, der auch Prüfungen für Drohnenpilotenzeugnisse anbietet. Das KI-Prüfverfahren wird von Droniq bereits angeboten.

Wer bisher eine größere Drohne mit einem Gewicht von über 900 g steuern will, muss einen entsprechenden theoretischen Nachweis erbringen, der ihn dazu befähigt. Dazu gehört etwa das Fernpiloten-Zeugnis A2. Diese Prüfungen finden unter der Aufsicht eines Prüfers statt. Dadurch soll verhindert werden, dass der Prüfling schummelt.

Bisher sind solche Prüfungen bereits online möglich gewesen. Die Überwachung der OPE-Prüfung erfolgt dabei mittels zweier Webcams: Die eine nimmt den Prüfling auf, die zweite ist auf die Tastatur gerichtet. Die Streams der Kamerabilder werden dann von einem Prüfer überwacht. Die Hardware-Voraussetzungen mit zwei Kameras setzen die Hürden für die Prüfung bereits hoch. Zusätzlich muss der Prüfling einen festen Termin dafür vereinbaren, um sie dann, häufig an einem Werktag, ablegen zu können.

Das KI-Online-Prüfungsverfahren läuft ähnlich ab, kann jedoch nun rund um die Uhr absolviert werden. Dabei wird lediglich eine Kamera benötigt, die den Prüfling aufnimmt. Das Kamerabild wird von einer KI überwacht, teilweise ausgewertet und bei Unstimmigkeiten im Nachgang von einem menschlichen Prüfer begutachtet.

Am Anfang der Prüfung wird ein Referenzbild des Prüflings erstellt, das zum Abgleich dient. Damit soll dafür gesorgt werden, dass keine andere Person die Prüfung absolviert und die KI weiß, wer der Prüfling ist. Die KI überwacht während des Prüfverfahrens „auffälliges Verhalten“ des Prüflings. Dazu gehört etwa das häufige Wegsehen und Sprechen. Geschieht das, markiert die KI die entsprechenden Videosequenzen, die dann hinterher von einem menschlichen LBA-zertifizierten Prüfer ausgewertet werden. Bei Unstimmigkeiten kann der Prüfling durchfallen. Die Auswertung der Antworten erfolgt automatisch. Das Ergebnis liegt dann innerhalb von zwei Werktagen vor.

Für die Prüflinge hat dieses KI-gestützte Prüfverfahren mehrere Vorteile: Die Hardwareanforderungen beschränken sich auf einen PC mit Internetanschluss und lediglich eine Kamera. Die Prüfung kann außerdem jederzeit erfolgen und sie wird um rund 50 Prozent günstiger, verspricht Droniq.

Verwendet wird die KI des US-Unternehmens Proctorio, ein Spezialist für die Online-Beaufsichtigung von Prüfungen. Die Abwicklung erfolgt DSGVO-konform über den tschechischen Online-Lernanbieter Aviatioexam, einem Partnerunternehmen von Droniq. Aviatioexam bietet auch Online-Prüfungen für die bemannte Luftfahrt an.

Droniq will das Prüfverfahren auf weitere Drohnenzeugnisse ausweiten und in verschiedenen Sprachen anbieten. Ab August soll das KI-Prüfverfahren auch beim Fernpiloten-Zeugnis für die Durchführung von Standardszenarien (STS) angewendet werden können.


(olb)



Source link

Weiterlesen

Künstliche Intelligenz

Warum Softwareentwicklung oft wie ein Escape Room ist


Ich habe vor kurzem eine Analogie gehört, die auf den ersten Blick ungewöhnlich wirkt, sich bei näherem Nachdenken jedoch als erstaunlich treffend erweist:

„Softwareentwicklung ist wie ein Escape Room.“


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Je länger ich über dieses Bild nachgedacht habe, desto passender erschien es mir. Und weil ich diesen Vergleich für ausgesprochen gelungen halte, widme ich ihm heute diesen Beitrag. An dieser Stelle übrigens ein herzliches Dankeschön an Jörg für diese großartige Analogie.

Stellen Sie sich also vor, Softwareentwicklung wäre wie ein Escape Room. Nur eben – ein bisschen anders. Oder genauer gesagt: ganz erheblich anders. Denn in diesem Escape Room hat ihn zuvor niemand für Sie getestet. Es hat Ihnen niemand gesagt, wie viele Räume es überhaupt gibt. Es existiert kein Spielleiter, der Ihnen Tipps gibt. Und es gibt nicht einmal die Garantie, dass überhaupt irgendwo ein Ausgang vorhanden ist. Das Beste daran: Während Sie sich darin befinden, zahlt jemand, der draußen wartet – und zwar auf Stundenbasis.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

Softwareentwicklung ist ein Escape-Room // deutsch

Das Ziel ist natürlich klar: Sie wollen einen Weg nach draußen finden. Im übertragenen Sinne heißt das: Sie möchten, dass die Anwendung live geht, dass das Feature deployed wird, dass die CI/CD-Pipeline grün ist und die Kundin oder der Kunde zufrieden. Nur: Wie genau Sie dorthin gelangen, weiß zu Beginn niemand.

In einem Escape Room erhalten Sie immerhin ein kurzes Briefing, etwa:

„Sie haben 60 Minuten Zeit, hier ist Ihre Geschichte, viel Erfolg!“

Am Ende, egal ob Sie es geschafft haben oder nicht, öffnet jemand die Tür und sagt:

„Immerhin, Sie haben es versucht und ein paar Schlösser geknackt.“

In der Softwareentwicklung läuft das etwas anders:

„Wir benötigen dieses Feature so schnell wie möglich, am besten gestern.“

Wenn Sie dann nachfragen, was das Feature denn genau leisten soll und worum im Detail es gehe, kommt häufig eine Antwort wie:

„Ach, das ist nicht viel, nur ein paar Buttons.“

Das klingt harmlos – bis Sie die Aufgabe genauer betrachten und feststellen, dass dort im Grunde steht:

„Bitte entwickeln Sie uns kurzfristig ein Flugzeug. Nur eben ohne Tragflächen, die können wir später ergänzen. Aber fliegen sollte es schon jetzt.“

Dann betreten Sie also Ihren Escape Room. Sie öffnen die erste Tür, stoßen auf das erste Rätsel – zum Beispiel: Welche Schnittstellen benötigen wir? Liefern diese tatsächlich die Daten, die laut Confluence dokumentiert sind? Oder kommt am Ende lediglich ein leeres JSON-Objekt zurück, weil irgendjemand irgendwo ein return hingeschrieben hat, dabei jedoch den Rückgabewert vergessen hat?

Trotzdem denken Sie sich, dass alles in Ordnung sei und Sie das schon irgendwie hinbekommen werden. Und tatsächlich lösen Sie das erste Rätsel. Sie öffnen die nächste Tür – und stehen plötzlich in einem Raum mit zwölf weiteren Türen, einer Falltür und einem zufällig umherfahrenden Laser, der Ihnen zuerst einmal Ihren gesamten Data-Layer zerschießt.

So geht es weiter. Manchmal lösen Sie ein Problem und sind sicher, es fast geschafft zu haben. Dann öffnen Sie die nächste Tür – und plötzlich bricht die Performance komplett ein. Oder die Security wird zum Problem. Oder Ihre CI/CD-Pipeline stürzt ab. Selbstverständlich nur bei jedem zweiten Durchlauf, mit einer ominösen Meldung wie „exit code 137“, einfach weil Jenkins gerade beschlossen hat:

„Nö, heute mal nicht.“

Vielleicht stellen Sie auch fest, dass das Legacy-System auf der Gegenseite noch auf Java 6 läuft, ausschließlich SOAP spricht und aus unerfindlichen Gründen zufällige Timeouts produziert. (Spoiler: Die Timeouts sind gar nicht zufällig. Das System hasst Sie einfach.)

Dann natürlich der Klassiker:

„Also bei mir läuft’s.“

Diesen Satz kennen Entwicklerinnen und Entwickler zur Genüge. Natürlich läuft es bei der Kollegin oder dem Kollegen auf dem Notebook, weil dort die Umgebungsvariable NODE_ENV auf „chaos“ gesetzt ist und noch fünf Docker-Container von vor drei Jahren laufen, die aber ausschließlich auf diesem einen Rechner jemals funktioniert haben.

Mitunter sieht ein Problem riesig aus, lässt sich dann jedoch in zwei Tagen erledigen, weil irgendeine Library es längst gelöst hat. Manchmal halten Sie es für trivial – und es kostet Sie Wochen, weil Sie plötzlich Merge-Konflikte in Dateien haben, die eigentlich gar nicht mehr existieren (sollten). So nach dem Motto:

„Warum liegt hier eigentlich noch eine package-lock.json von 2018 herum?“

In einem Escape Room hängt immerhin eine Uhr an der Wand. 60 Minuten, dann ist Schluss. In Softwareprojekten hingegen heißt es meist:

„Wir schätzen das auf etwa drei Monate.“

Was, wenn man ehrlich ist, bedeutet:

„Drei Monate plus minus alles.“

Denn Sie wissen schlicht nicht, ob Sie hinter der nächsten Tür ein kleines Zahlenschloss finden oder eine riesige Hydra aus zwanzig Services, die sich gegenseitig aufrufen und natürlich komplett auseinanderfallen, sobald Sie versuchen, auch nur einen davon zu aktualisieren.

Dann treten die Stakeholder auf den Plan. Im Escape Room stehen die wenigstens nicht mit Ihnen im Raum. In Softwareprojekten schon. Oder sie kommen alle fünf Minuten herein und fragen:

„Könnt ihr kurz zeigen, wie weit ihr schon seid?“

Und das, während Sie gerade herauszufinden versuchen, warum Ihr Deployment plötzlich alle Assets verschluckt und der Health-Check Ihrer API neuerdings nur noch den HTTP-Status-Code 418 zurückliefert („I’m a Teapot“). Wie sieht der Fortschritt also aus, den Sie zeigen könnten? Ein komplett rotes Dashboard und ein Entwickler, der seit drei Stunden reglos auf sein Terminal starrt …

Mein persönliches Lieblingsrätsel sind die Anforderungen. Am Anfang heißt es:

„Wir brauchen nur dieses eine Feature.“

Eine Woche später:

„Ach übrigens, könntet ihr das bitte alles Event-basiert umsetzen? Oder doch lieber mit synchronen REST-Calls? Am besten noch mit Dark Mode, Predictive AI und einem Self-Service-Portal, das Forecasts für die nächsten zwölf Monate liefert.“

Klar, warum nicht. Für mich entwickeln sich Requirements oft wie Pokémon: Zuerst ist es nur ein kleiner Button. Dann wird es ein Formular. Und irgendwann mutiert das Ganze zu einem Workflow mit OAuth, Approval-Chain und einem komplexen Dashboard.

Wenn man das – vielleicht etwas nüchterner als hier – im geschäftlichen Alltag zu erklären versucht, kommt garantiert jemand und sagt:

„Aber beim Hausbau geht das doch auch.“

Ja, aber wissen Sie was? Beim Hausbau ist auch alles bekannt. Da gibt es einen Plan. Hier stehen die Wände, dort kommen die Fenster hin, fertig. Kein Architekt kommt zwei Monate nach Baubeginn auf die Baustelle und sagt:

„Wir haben uns das noch einmal anders überlegt. Das Dach hätten wir jetzt gern aus Käse.“

In der Softwareentwicklung passiert genau das – und zwar ständig. Entweder, weil die Kundin oder der Kunde merkt, dass eigentlich etwas ganz anderes benötigt wird. Oder weil Sie unterwegs feststellen, dass sich unter dem Fundament noch ein riesiger Sumpf aus Altlasten verbirgt. Oder aus hundert anderen Gründen. Dann sind Sie schon froh, wenn Sie zumindest ein paar stabile Pfosten einziehen können, bevor Ihnen alles absäuft.

Wie geht man damit um? Indem man iterativ arbeitet. Man versucht nicht, den gesamten Escape Room mit allen Rätseln auf einmal zu lösen, sondern nimmt sich ein Rätsel nach dem anderen, Raum für Raum, Tür für Tür. Man testet regelmäßig, schreibt Logs (bevor es knallt), baut Metriken ein, macht Fehler früh sichtbar. Und man hat vor allem keine Angst, einmal das Licht anzuschalten und nachzusehen, was dort wirklich kreucht und fleucht.

Dabei macht das Team einen erheblichen Unterschied. Es ist ein großer Unterschied, ob Sie mit einem eingespielten Team von drei Personen in einem Escape Room stehen, die das schon hundertmal gemacht haben – oder mit einem Haufen planloser und nervöser Menschen, die von nichts eine Ahnung haben. Ein gutes Team erkennt Muster. Ein gutes Team weiß, wo man Tests sofort hinschreibt, statt später hektisch die Coverage zu schönen. Ein gutes Team baut Logging nicht erst dann ein, wenn es bereits brennt. Und es richtet CI/CD nicht fünf Minuten vor Schluss ein, wenn die Kundin oder der Kunde schon danebensteht und fragt, warum auf Staging noch das Feature von letzter Woche läuft.

Aber auch das beste Team kann Ihnen nicht garantieren, dass sich hinter der nächsten Tür nicht ein Monster verbirgt, das sagt:

„Hallo, ich bin Ihr zehn Jahre altes Legacy-CRM. Ich spreche nur EBCDIC und bin fest verdrahtet mit einer Oracle-Version, die offiziell seit 2012 nicht mehr unterstützt wird.“

Wenn Sie auf dieser Datenbank dann einmal ein SELECT ausführen, erhalten Sie entweder 200.000 Zeilen – oder eben gar nichts. Bei derselben Query, mal so, mal so. Aus Gründen.

Doch irgendwann kommt (hoffentlich) dieser Moment, in dem Sie tatsächlich vor der finalen Tür stehen. Alle Tests sind grün. Die Pipeline läuft. Das Deployment ist sauber. Das fühlt sich ungefähr so an, wie wenn Sie im Escape Room den letzten Schlüssel drehen, die Tür aufspringt und draußen jemand mit einer Konfettikanone auf Sie wartet. Zumindest so lange, bis jemand sagt:

„Könnten wir jetzt noch schnell einen Admin-Bereich einbauen? Am besten bis morgen, das wäre super.“

Das Schöne daran ist: All das gehört irgendwie auch dazu und macht ein Stück weit den Reiz dieses Berufs aus. Softwareentwicklung ist ein Escape Room. Nur größer, chaotischer, unvorhersehbarer. Manchmal extrem nervenaufreibend, manchmal frustrierend, aber immer mit diesem kleinen Kick, wenn Sie ein Rätsel gelöst haben. Wenn Sie eine Tür öffnen und dahinter nicht noch ein Drache wartet, sondern tatsächlich der Ausgang. Dann können Sie hinausgehen, sich kurz schütteln und voller Stolz sagen, dass Sie es geschafft haben. Zumindest bis jemand von hinten ruft:

„Übrigens, wir hätten da noch ein neues Projekt. Dieses Mal mit Machine Learning, IoT und Blockchain. Das sollte jetzt aber schnell gehen, oder?“


(rme)



Source link

Weiterlesen

Künstliche Intelligenz

Multilevel-Umrichter für E-Autos: Das Effizienzwunder, das niemand in Serie baut


Traktionsbatterien liefern Gleichstrom. E-Motoren in Autos funktionieren dagegen praktisch alle mit Drehstrom. Daher kommen zwischen diesen beiden Teilen Umrichter zum Einsatz. Der Stand der Technik im Autobau sind 2-Level-Umrichter. Sie schalten auf drei Phasen in hohen Frequenzen zwischen der Nennspannung der Batterie und dem Bezugspotenzial (im Auto: Masseleiter) hin und her. Die für die Wechselspannung typische Sinuskurve erzeugen die Geräte näherungsweise über Pulsweitenmodulation (PWM). Mittlerweile gibt es die ersten Zulieferer-Vorschläge von 3-Level-Umrichtern. Was aber, wenn man auf noch deutlich mehr Ebenen schalten würde, bis auf die Ebene Modul oder gar Zelle herunter?

Auf dieser Idee bauen Multilevel-Umrichter auf (Multi Level Inverters, MLI). Sie verschalten ad hoc Module oder Zellen so, dass die jeweils nötige Spannung herauskommt – näherungsweise gestuft, mit der Auflösung der Zell- oder Modulspannung. Das hat eine ganze Reihe von Vorteilen, aber auch einige Nachteile, auf die wir gleich näher eingehen. Porsche Engineering, Porsche-Tochter und internationaler Ingenieurdienstleister, hat zur Demonstration kürzlich ein MLI-System in einem Prototypenfahrzeug integriert.

  • Multilevel-Umrichter zeigen seit Jahrzehnten in allen Studien große Vorteile bei der Effizienz.
  • Gebaut wurden sie bisher trotzdem nicht in Serie.
  • Porsche Engineering zeigte nun einen weiteren vielversprechenden Prototypen.
  • Ungeachtet der Multilevel-Technik ist die Schalt-Hardware mit auf dem SoC integrierten FPGA besonders interessant.

Dieser Artikel beschreibt die Idee des Entwickler-Teams bei Porsche Engineering, setzt sie in Bezug zu vorherigen Designs und dem Serien-Elektroautobau und arbeitet so Potenziale sowie Vor- und Nachteile heraus. Interessanterweise sitzt der Teil des Aufbaus, der es am ehesten in Serienautos schaffen könnte, in einer sehr interessanten SoC-Konstruktion der Steuerungsplatine.


Das war die Leseprobe unseres heise-Plus-Artikels „Multilevel-Umrichter für E-Autos: Das Effizienzwunder, das niemand in Serie baut“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.



Source link

Weiterlesen

Beliebt