Die US-amerikanische Verkehrssicherheitsbehörde NHTSA (National Highway Traffic Safety Administration) hat eine Untersuchung gegen Tesla eingeleitet. Grund: Das Unternehmen soll Unfälle, die sich im Zusammenhang mit seinen Fahrassistenz- und Selbstfahrfunktionen wie „Autopilot“ ereigneten, viel zu spät gemeldet haben. Anstatt die Vorfälle, wie vorgeschrieben, innerhalb von fünf Tagen zu melden, reichte Tesla die Berichte erst Monate nach den Unfällen ein.

Die Behörde konzentriert sich laut einer Meldung der Nachrichtenagentur Associated Press (AP) bei ihrer Prüfung auf die Frage, warum die Meldungen so lange verzögert wurden, ob die Berichte vollständig waren und ob es womöglich noch weitere bisher unbekannte Unfälle gibt. Tesla selbst gab an, die Verzögerungen seien „auf ein Problem mit Teslas Datenerfassung zurückzuführen“, das man inzwischen behoben habe.

Diese neue Untersuchung kommt zu einem kritischen Zeitpunkt: Tesla hat erst vor Kurzem in Austin einen Service mit selbstfahrenden Taxis gestartet. Der Konzern von Elon Musk plant, Robotaxi-Dienste bald landesweit anzubieten. Ferner will der E-Autobauer Millionen von Fahrzeugen mit Software-Updates ausstatten, die autonomes Fahren ermöglichen sollen.

Nicht die erste US-Untersuchung bei Tesla

Obwohl die Umsätze und Gewinne von Tesla aufgrund von Boykotten wegen Musks langzeitige Unterstützung für US-Präsident Donald Trump und rechtsextreme Politiker in Europa sinken, hält sich der Aktienkurs des Unternehmens weiterhin auf hohem Niveau. Analysten führen dies auf die Begeisterung der Investoren für die „Autopilot“-Pläne des Konzerns zurück.

Die aktuelle Prüfrunde ist nicht die erste: Bereits im Oktober startete die NHTSA eine Untersuchung wegen möglicher Probleme mit Teslas „Autopilot“-System bei schlechter Sicht. Diese betrifft 2,4 Millionen Fahrzeuge und steht im Zusammenhang mit mehreren Unfällen, darunter einem tödlichen. Ein US-Geschworenengericht entschied jüngst: Tesla trägt eine Mitschuld an diesem Crash mit Todesfolge. Das Unternehmen soll Schadenersatz von insgesamt mehreren hundert Millionen US-Dollar zahlen, wehrt sich vor Gericht aber gegen diesen Beschluss. Seit Juni analysiert die NHTSA zudem Tesla-Vorfälle mit potenziellen Verstößen gegen Verkehrsregeln.

Sinkende Einnahmen: „Autopilot“ soll es richten

Seit 2021 müssen Fahrzeughersteller in den USA Unfälle mit teilautomatisierten Fahrsystemen (SAE-Stufe 2) melden. Von den insgesamt über 2600 gemeldeten Crashs in den Vereinigten Staaten entfallen mit 2308 die meisten auf Tesla. Die NHTSA weist jedoch darauf hin, dies liege auch daran, dass das Unternehmen der größte Hersteller von teilweise selbstfahrenden Autos auf dem US-Markt ist.

Tesla bot in Austin bisher nur einem ausgewählten Kreis von Fahrgästen Robotaxi-Fahrten an. Ab September soll mit einer neuen Offensive allen zahlenden Kunden die Nutzung solcher Shuttles möglich sein, wie Musk auf X Anfang August ankündigte. Tesla hat außerdem begonnen, in San Francisco eingeschränkte Robotaxi-Dienste mit Fahrern am Steuer zuzulassen, um den kalifornischen Vorschriften zu entsprechen. Als größter Konkurrent gilt die Google-Schwester Waymo, die bereits über eine Million Fahrten pro Monat mit Robotaxis absolviert. Auch Europa hat Musk bei solchen Fahrten im Visier, wenn die Behörden die neuen Versionen der „Autopilot“-Software abgenickt haben.

(nie)

Microservices, Container und Cloud-Technologien machen Software-Entwicklung zu einem immer komplexeren Geschäft. Vorkonfigurierte Entwicklerplattformen, die sogenannten Internal Developer Platforms (IDP), versprechen da Abhilfe. Als Selbstbedienungsportale für die benötigte Infrastruktur sollen sie kognitive Last verringern und mehr Konzentration auf den Code erlauben. Guido-Arndt Söldner, Titelautor der neuen iX 9/2024, erklärt, was hinter dem Heilsversprechen steckt und wann sich eine solche Plattform tatsächlich lohnt.

Was genau ist denn eine Internal Developer Platform (IDP)?

Eine Internal Developer Platform ist eine zentrale Plattform, die von einem Platform-Engineering-Team erstellt wird, um Entwicklern standardisierte und bewährte Wege für die Softwareentwicklung zu bieten und Self-Service-Funktionen zu ermöglichen. Sie umfasst eine Sammlung von Tools und Services, die die Produktivität der Entwickler steigern, die Softwarebereitstellung beschleunigen und manuelle Operationen reduzieren. Im Kern abstrahiert eine IDP die Komplexität der zu Grunde liegenden Infrastruktur, sodass Entwickler sich auf das Coden konzentrieren können, ohne sich mit Details wie Deployment, CI/CD oder Environment-Management auseinandersetzen zu müssen.

IDPs fördern auch eine bessere Developer Experience, senken Kosten und sorgen für Konsistenz in der Organisation. In jüngster Zeit halten IDPs auch in der Infrastruktur-Automatisierung ein, um klassische Ticket-Ops Aufgaben wie Ressourcen-Anlage, Firewall Management, Rechte-Vergabe oder ähnliches zu automatisieren.

Über welche Tools sprechen wir? Geht es um lokale Programme oder das Backend?

Bei IDPs geht es primär um Backend-Tools und -Services, nicht um lokale Programme auf dem Entwickler-Rechner. Lokale Tools wie IDEs (z. B. VS Code) oder einfache Skripte spielen eine untergeordnete Rolle; stattdessen fokussiert sich eine IDP auf cloud-basierte oder interne Backend-Systeme, die Infrastruktur automatisieren und skalierbar machen. Sie dient als Frontend und Self-Service Portal für einen typische Platform Engineering Stack, der aus Komponenten wie CI/CD-Pipelines, Infrastruktur-Management, Observability und Monitoring sowie Security und Governance besteht.

Für welche Organisationen lohnt es sich, eine IDP aufzusetzen? Wie kompliziert ist das Aufsetzen einer IDP?

IDPs lohnen sich vor allem für mittelgroße bis große Organisationen, in denen die Softwareentwicklung skaliert werden muss und Komplexität zunimmt. Kleine Startups oder Teams mit niedriger Komplexität brauchen oft keine IDP, da sie teuer und übertrieben sein kann – stattdessen reichen einfache DevOps-Praktiken. Sie sind ideal bei großen Developer-Teams so ab 50 und mehr Entwicklern, um Produktivität zu steigern und Cognitive Load zu reduzieren. Sie helfen, wenn Tool-Sprawl und Silos ein Problem darstellen, etwa in Unternehmen mit einer Multi-Cloud-Strategie und wenn schnelle Release-Zyklen gewünscht sind. Sie helfen auch Visibilität über Tools und Cloud-Umgebungen herzustellen.

Das Aufsetzen und Administrieren einer IDP kann größere Aufwände mit sich ziehen. Es lohnt sich, zu überlegen, ob man alles selber entwickeln und betreiben will oder mittels externer Hilfe beziehungsweise fertigen Lösungen und dedizierten Plugins schneller zum Ziel kommen kann. Insgesamt gibt es eine Vielzahl von IDP-Projekten, die sich in Offenheit, Fokus, Komplexität und Features unterscheiden. Open Source IDPs wie Backstage kann man als SaaS-Dienst oder auch im eigenen Rechenzentrum souverän betreiben. Sie bieten oft eine hohe Flexibilität, können leicht angepasst werden und haben eine sehr große Community. Es gibt immer mehr fertige Lösungen für unterschiedliche Use Cases.

Im Eigenbetrieb kann aber ein höherer Overhead entstehen. Kommerzielle Portal-Lösungen glänzen mit schnellem Onboarding und weniger Betriebsaufwänden, sind aber oft inflexibler hinsichtlich Erweiterungen.

Guido-Arndt, vielen Dank für die Antworten! Einen Überblick zu Internal Develeoper Platforms gibt es in der neuen iX. Außerdem vergleichen wir IDPs für Kubernetes – und werfen einen Blick auf die Praxis mit der populären Plattform Backstage. All das und viele weitere Themen finden Leser im September-Heft, das ab sofort im heise Shop oder am Kiosk erhältlich ist.

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(axk)

Die Medion GmbH ist erst seit Anfang des Jahres vollständig im Besitz von Lenovo, das aber schon seit 2011 die Mehrheit an dem deutschen Elektronikhändler hielt. Jetzt hat sich der Konzern von einem Großteil der Beteiligung wieder getrennt, wie die Wirtschaftswoche berichtet.

Lenovo behält nur noch die PC-Sparte und wird weiter unter den Markennamen Medion und Erazer Notebooks und PCs produzieren. Alles andere, also Haushaltelektronik, TV-Geräte, Wearables und auch der Aldi-Talk-Vertrieb, gehört jetzt zu einer neu gegründeten Medion GmbH. Die soll sich auch um Vertrieb und Marketing der Medion- und Erazer-PCs kümmern, Lenovo agiert nur als OEM-Lieferant. Der Medion-Onlineshop läuft bereits unter dem neuen Unternehmen.

Eigentümer der GmbH ist Gerd Brachmann, der 1983 das Unternehmen gemeinsam mit einem Geschäftspartner gründete und 1999 an die Börse brachte. Brachmann blieb auch nach der Übernahme als Geschäftspartner an Bord.

Krise nach langem Boom

Durch die Kooperation mit Aldi wuchs Medion in den „Nullerjahren“ zu einem der größten Elektronik- und Computerhändler Deutschlands heran und war mit Aldi Talk auch im Telekommunikationsgeschäft eine feste Größe. Zuletzt geriet das Unternehmen regelmäßig in die Verlustzone. Die neue Gesellschaft peilt für das laufende Geschäftsjahr ein Ergebnis von 10 Millionen Euro bei 600 Millionen Euro Umsatz an.

Über den Kaufpreis des Unternehmens ist nichts bekannt. Die meisten Mitarbeiter wechseln laut Wirtschaftswoche in die neue GmbH. Lediglich 23 Angestellte verbleiben bei Lenovo. Kurz vor dem Rückkauf durch Brachmann wurde ein neuer Kooperationsvertrag mit der Servicegesellschaft von E-Plus, einem Tochterunternehmen von Telefónica, geschlossen, die das Netz für Aldi Talk zur Verfügung stellt.

(ulw)