Reusable Embedded Security Platform
Initial situation
Across several automotive projects, embedded systems had to integrate security functionality. HSM integration, cryptographic services and security integration paths became recurring technical tasks.
Challenge
When each project interprets these topics again, coordination effort rises, integration patterns diverge and technical risks become harder to plan. The solution had to be reusable across projects without assuming that all projects were identical.
Role and approach
The work focused on building and evolving a reusable embedded security platform. This included standardized integration approaches, integration of HSM and cryptographic services, and technical guidance for using platform structures across several projects.
Impact
In this context, security integration effort was reduced by approximately 75 percent. More important than the number was the chain of effects: reuse, less repeated coordination, simpler integration of additional software modules, better planning and more efficient long-term engineering through a platform approach. Further development was technically owned across more than 15 projects per year.
What this example shows
Platform Security is not only a protection concept. When structured properly, it becomes a reusable platform capability that connects architecture, integration and engineering enablement.
End-to-End Software-Defined Vehicle Architecture
Initial situation
In the context of an end-to-end software-defined vehicle, existing technical solutions and architectures had to be analyzed, evaluated and brought into a consistent overall picture.
Challenge
The work was not about a single software module. Existing technologies and architectures had to be understood, evaluated and brought into a consistent overall picture from the full vehicle through system, domain and platform levels down to embedded and microcontroller-level systems.
Role and approach
A central part was technical decision guidance for execution and isolation technologies such as Linux, containerization, sandboxing, microkernels and hypervisors. Selection was derived from ASIL levels, QM context, security requirements, criticality, system and software boundaries, required isolation and mutual influence between functions. This was combined with architecture concepts and the adaptation of existing technologies for the overall architecture.
Impact
The architecture was aligned with key architects working across the wider organization, presented to technical decision-makers and led to numerous further technical discussions. The results were documented in several articles in an internal documentation and recommendation system, making the insights reusable across the organization. The architecture work resulted in several invention disclosures; some resulting inventions are in a subsequent patenting process.
What this example shows
This example shows architecture trade-off analysis at system level: requirements, safety/security criticality and required isolation are translated into traceable architecture mechanisms. The value is not the term SDV, but a decidable end-to-end architecture.
Local AI-Assisted Engineering Knowledge System
Initial situation
The starting point was the departure of an experienced expert and the risk that important engineering knowledge would become hard to find or use. Later, personal knowledge was also prepared so others could use it after the creator had left.
Challenge
This was not a general AI topic. Confidential documents, source code and internal knowledge had to remain inside controlled boundaries. At the same time, existing knowledge had to become findable, analyzable and traceably usable.
Role and approach
A local RAG-based system was developed. Local processing, access protection, traceability and security by design were architecture requirements. AI was used as a technical component to make engineering knowledge structurally accessible.
Impact
The system made knowledge and recurring support partially available and reduced personal dependencies. It did not replace a person; it helped keep existing engineering experience usable in a controlled way.
What this example shows
AI-assisted engineering becomes robust when treated as a Systems Architecture and Platform Security task. AI is the tool, not the business purpose.
Making Extensive Security Requirements Decidable
Initial situation
Projects regularly had more than 500 detailed requirements, including security-specific requirements, spread across many Excel sheets, PDFs and emails. Project management and engineering teams needed a clear view of which requirements were relevant, feasible or still open.
Challenge
Large requirement sets can quickly create false precision. The important part is not only collecting requirements, but making their technical contribution, open assumptions, exclusions, risks and affected components visible.
Role and approach
The involved colleagues received a technical structure for sorting the requirements themselves: affected software components, platform capabilities, effort, risks, assumptions and exclusions. This enabled them to make the requirement chaos transparent for project management and the engineering teams.
Impact
Technical decisions became more traceable. Other disciplines could derive which contributions were needed in their components. Systems Architecture was therefore not treated as greenfield design, but as clarification of complex existing dependencies.
What this example shows
Robust architecture work often happens where requirements, existing systems, multiple teams and open decisions need to be brought into a shared technical view.
Turning Engineering Knowledge into an Enablement System
Initial situation
Technical knowledge around Platform Security and Security Engineering was embedded in project experience, recurring workflows and many detailed decisions. New engineers had to understand this knowledge before they could work independently.
Challenge
Simple handovers or occasional explanations are not enough in such situations. Knowledge has to become findable, understandable and durable without turning engineering enablement into a formal training product.
Role and approach
Since 2021, technical knowledge was captured from the beginning in internal wiki articles, documents and how-tos. Recurring technical workflows were also documented in explanatory videos. Biweekly Security Engineering Insights made abbreviations, terminology, responsibilities, module roles and cost implications understandable for non-security teams. This was complemented by implementation concepts, technical guidance and review structures.
Impact
The individual artifacts gradually became an onboarding and enablement system. Over five years, around 15 engineers were trained in Platform Security or Security Engineering. Knowledge was no longer tied only to individual people.
What this example shows
Engineering Enablement works when architecture decisions, how-tos, reviews and knowledge transfer become part of the technical solution. The goal is not more documentation, but teams that can work.
Cross-Project Technical Coordination and Effort Transparency
Initial situation
Numerous projects needed support at the same time. Technical questions connected project management, development teams, security owners and other specialist functions.
Challenge
Cross-project technical support only works when assessments are robust and traceable. Effort estimates need to show scope, assumptions, risks and exclusions without implying budget or personnel responsibility.
Role and approach
The work consisted of technical coordination, effort estimates and preparing decision foundations. The goal was to bring different technical roles into a shared view and structure open points so decisions became possible.
Impact
Transparent, robust and goal-oriented assessments built trust in the technical evaluation. As reputation increased, technical assessments were accepted as decision support. The reference to more than 15 projects per year is used only to describe the cross-project context.
What this example shows
Technical judgment is visible not only in designing individual systems, but also in structuring complex project situations calmly, traceably and decisively.
A similar technical situation?
An initial conversation clarifies the current situation, the decision that is needed and whether an assessment, review or concrete architecture mandate is appropriate.