I joined Scania to build the way towards driverless hub-to-hub transport solutions. I am working on technical level with defining system design and safe operations of AD components. I was involved in the Functional Safety Concept work and further early process safety work. As the AD development is still in early phase we are struggling with all the uncertainties of a low maturity research project.

Cascade Drives AB is a small startup, whose main activity is gearbox design. As the company planned to offer an ADAS lvl4 ready steering system with their patented gearbox, they were looking for someone who can support the integration of the sourced E/E components and the compliance for ISO26262 at the same time. After getting hired I immediately began with setting up the processes and templates to ensure that the documentation needed for ISO26262 certification will be produced on all levels of the development. Parallel to this I defined the DIA between OEM, Cascade Drives, and the E/E supplier. After finishing the DIA, I set up a requirement management system (easeRequirements), and as the OEM started to formulate the expectations, I took care of the system design. This involved describing the system state machine, sequence diagrams for switchover between the motors, required self-diagnostics, safety mechanisms and finally writing the requirements once the behaviour was agreed. To support the homologation, I calculated the state-space model of the steering assembly (2DoF) and provided the OEM with other steering related performance and dynamics calculations. Apart of the above I took care of the System FMEA and worked on the TSC and safety analysis together with the safety manager.

At Stoneridge I continued to work with computer vision as a system architect for the MirrorEye2 product, which is a mirror replacement camera system for trucks, with overlays and ASIL-B requirements. Since I got hired a bit more than a year before the internal SOP the main goal was to ensure at least level 2 ASPICE compliance and the full traceability of the functional safety requirements. One of my major tasks was to negotiate the logical requirements with the customer, trace the customer requirements to system, and keep the overall DoorsNG database clean on system level and above. This involved drawing and analysing feature state diagrams, ensuring that we have the same understanding. My other major task was to keep the diagnostic level information synchronised and up to date between SRE and the OEM, create new DTCs/routines and allocate them in the memory area. I also got the task to ensure compliance with ASPICE SYS.3 describe the system architecture in DoorsNG and be the shareholder on internal audits. Sporadically I was involved in FMEAs and SW level technical discussions when an issue spread across multiple components.My employment ended at Stoneridge due to the closure of the systems engineering department.

Process development at Zenseact

In the first 2 years at Zenseact (Zenuity at the time) my task was to develop a system development process that would fulfill both ASPICE level 3 and ISO26262 requirements, while posing as little administration effort on the developers as possible. The task was rather special since the process had to utilize SystemWeaver, a tool that is somewhat Volvo group specific, and it had to enable system development with the collaboration of more than 30 teams without any system architect in place. The reason for the latter is that Zenseact worked on the complete AD/ADAS software (from perception to actuation) and it was impossible to appoint one system or SW architect who could overview the development of all the 30+ different subsystems and the different teams owning them. The solution was an inbox-outbox way of working on several levels, where each team would be responsible of breaking down the requirements from their inbox and further allocating them to the connecting lower level subsystems while defining interfaces in collaboration with each other. When designing this process, I encountered Conway’s law and decided not to try and fight with it, instead propose organizational changes to the management if the product structure required it. Thanks to the flexibility and flat hierarchy of Zenseact this was widely accepted.

After long meetings with dev teams and several iterations of the SystemWeaver metamodel, the system design process was officially released. With this process in place the requirements had their way to reach from the functional level down to component level. To ensure the complete chain of traceability, the last task was to connect the requirements in SystemWeaver with the production code and result database. When the system design process got released I provided personalized trainings for the development teams and onboardings for the new colleagues. 

System design at Zenseact

My original goal at hiring was to work on the design of the camera vision subsystem which had requirements up to ASIL-C, but at that time there was no way how the requirements from functional level would reach the lower levels, therefore did I take the initiative to work out the process. After the process was roughly defined, the teams started to test and follow it, thus requirements started to appear in our inbox. For about a year I worked parallel on smoothing out the rough edges of the system design process, and at the same time utilizing the process: analysing, breaking down and negotiating the requirements and the architecture of the vision subsystem with the function developer teams. The best practice I proposed was to utilize FTA analysis for every ASIL requirement breakdown, so in this time I was lead several FTAs. After we had a decent requirement base in SystemWever the next challenge appeared: While the product was still in early phase on concept level the SW was in way more mature stage than the design. So the next challenge was to trace the requirements resulting from high level design to the mostly existing implementation. It was clear that SystemWeaver offers only a very tedious way of coupling design with SW implementation, so we decided to introduce a new open-source tool called Doorstop.

Since I worked previously on the process on higher level, I got the task to define how Doorstop should be used to trace requirements from SystemWeaver to the production code in git to simplify generating coverage and code quality metrics. Since Doorstop is a rather simple tool, a lot of features essential for ASPICE and ISO26262 were missing. In my last 1,5 years at Zenseact I worked mostly on this tool together with two developers from Ukraine in order to settle the complete traceability from system requirements to test results across different tools. Doorstop is written in python and the requirement database are in the same repository where the production code is stored, thus simplifying versioning between requirements and implementation, here is a list of the most important features I added:

• Synchronization interface fetching requirements from the SystemWeaver production environment to the Doorstop structure of the local repository as .yaml files
• Version controlled tracing of requirements to .cpp classes
• Expanding the Doorstop integrity check with changes in the implementation code and validating ASIL requirement breakdowns
• Doorstop has a command line interface, so we added a user-friendly UI using streamlit
• One click generation of test catalogues, customizing, downloading and uploading through the UI

The documentation of the tool, the process description and the onboarding/training of the current and new developers was also my responsibility. My latest knowledge is that the company

Vehicle testing and application at Bosch

As my first job after graduation, I was working on the Bosch Smart Rear View Camera, a one box solution fusing ultrasound with video and providing an enhanced picture with overlays via SomeIP Ethernet. In the first year my task was to carry out the application of the cameras to different vehicle variants and execute the vehicle level integration tests on customer site (Munich).

Systems engineering at Bosch

After about a year as an application and vehicle test engineer, I started to get involved more in systems engineering topics. The first major step was taking on the Problem Manager role. In this role my responsibility was to analyze the customer reported issues (QCs) and find out where the root cause lies. It could have been the host vehicle, the measurement equipment, or one of the SW modules of our camera (usually ComStack, or Application). The analysis included checking the traces, comparing the behavior with the requirements, allocating the issue on the developers with a recommendation on the fix, or reasoning towards the customer why we are rejecting the claim. In this role I have gotten very familiar with SomeIP Ethernet, CAN, UDS diagnostics, Vector tools (CANoe), AUTOSAR, and learned the significance of functional safety (the rear-view camera was ASIL A, the surround view was ASIL B). I really enjoyed this kind of investigative work, so I took the same role for the Surround Vision System, which was a more complex product with advanced algorithms, one main ECU, 4 cameras, and the 3D recreation of the vehicle and its environment. Thanks to my rapidly increasing domain knowledge I’ve gotten involved in evaluating change requests, solution design, FMEAs, and requirement breakdown. I even had the chance to work on study concepts, since Bosch wanted to expand its video division into the offroad market, so to showcase our product we equipped agricultural tractors with surround vision. This meant from doing the cabling, fitting the camera to setting up carPCs and writing the gateway in CANoe, as well as application and the final demo to the possible customers. This was also a very interesting activity, the most hands-on engineering I’ve ever done. Speaking about demos, thanks to my diplomatic skills in handling unsatisfied customers I was involved in a lot of sales pitches.

After 2 years at Bosch, I became the technical team lead of my team of 7 near range camera engineers. This included 1on1s, aligning with each team member on the current pain points, planning the competence building, and generally ensuring a harmonic work load and scope that fits the skills and ambitions of the individual. On a resource management level I was responsible for work allocation, team load and competence planning, personal performance monitoring and yearly reviews, skill development plans and hiring. In this role did I face the uniqueness of systems engineer hiring, and came up with a new practice that made the filtering of the candidates very effective.
As this wasn’t a full-time activity, rather around 30% of my load, I kept my system engineering role to stay up to date on the current challenges.