Search Results

For an established development process and a team accustomed to this process, adding cybersecurity features to the product initially means inconvenience and reduced productivity without perceivable benefits. Adapting development processes to take cybersecurity into account introduces challenges not present in engineering divisions so far. Strategies designed to deal with these challenges differ in the way in which added duties are assigned and cybersecurity topics are integrated into the already existing process steps. Cybersecurity requirements often clash with existing system requirements or established development methods, leading to low acceptance among developers, and introducing the need to have clear policies on how friction between cybersecurity and other fields is handled. A cybersecurity development approach is frequently perceived as introducing impediments, that bear the risk of cybersecurity measures receiving a lower priority to reduce inconvenience.

Today, highly automated driving is paving the road for full autonomy. Highly automated vehicles can monitor the environment and make decisions more accurately and faster than humans to create safer driving conditions while ultimately achieving full automation to relieve the driver completely from participating in driving. As much as this transition from advanced driving assistance systems to fully automated driving will create frontiers for re-designing the in-vehicle experience for customers, it will continue to pose significant challenges for the industry as it did in the past and does so today. As we transfer more responsibility, functionality and control from human to machine, technologies become more complex, less transparent and making constant safe-guarding a challenge. With automation, potential misuse and insufficient system safety design are important factors that can cause fatal accidents, such as in TESLA autopilot incident.

Achieving functional safety in mechatronic systems with growing product functionality is a major challenge in systems engineering. Following the current discussion, this challenge is mostly allocated to electronics and software development. For most of the scenarios this focus is feasible. Product design - the construction of the product - defines the properties and the appearance of the product by shape, material and assembly. So, the product design is often not under control of the safety management system. A hazardous deviation of part shape can be easily identified after the parts product or at least at its mounting. A wrong assembly is controlled by assembly documentation or data (e.g. screw torques) and identified at end of assembly line checks. The identification of a hazardous material choice depends on the product material class. Product materials can be separated into two classes: passive or active materials.

Functional Safety engineering aligned to an international standard is already a long-lasting discussion. Nevertheless, the requirements of process conformance to assure functional safety have been detailed in description and interpretation. The ISO 26262 is seen as state-of-the-art Functional Safety engineering basement in Europe, the closer interpretation of the IEC 61508 is claimed by assessors in America and Asia. This work shows how stagnation in engineering process improvement is solved by re-engineering projects. The benefits of re-engineering are described in this context. A four month, proven-in-practice project plan is explained. The expected results of such a project are given as generic goals for similar projects. A practice report shows the realistic outcome of such a project for the Chinese automotive industry. The report shows how the motivation of the involved engineers was gained and how existing engineering documentation was used in an efficient way.