As the leading international consulting firm for automotive electronics development, Kugler Maag Cie ensures that your R&D unit meets the requirements of Agile in Automotive, Automotive SPICE, Functional Safety, Cybersecurity and other industry standards.
With this channel, we provide knowledge and first-hand insights to Automotive engineering practitioners.
It was very useful. Thank you. Is it possible to explain what are the differences or changes from PAM 3.1 to PAM 4.0 for each of the process areas independently ?
The SWE.4 activities are typically done by the developers themselves, unless independence is required (e.g. because of Functional Safety requirements). We hope this helps you further!
Sorry for the inconvenience. Could you please specify which link you're using? In case you want to download the white paper, this link should work: www.kuglermaag.com/automotive-cybersecurity/software-update-management-system/. Let us know if you have any further issues!
Strictly taken are safety analyses not part of the architecture. But they are necessary to support the adequacy and correctness of the architecture. All together (architecture, analyses, …) these work products contribute to the safety concept. We hope this helps you further!
Normally system and sub system level functional requirements will be "what" the system should do not "how" or "implementation. When it comes to Functional Safety, is FSR and TSR written in "what" vehicle or System should do when failure occurs or is it "how"
In general requirements are more “what” must be done or implemented, not so much “how” to do or implement it. But of cause is a TSR already the “how” to implement a FSR. That kind of relationship applies to any hierarchical levels of requirements. We hope this helps you further!
In systems engineering, you define the system with its boundaries, interfaces and components. This is a logical segmentation of the product. This also implies that the definition of a system differs from your perspective: A car maker defines the car as a system, a tier1 or tier2 supplier calls their component a system, etc.. To address this constellation, Automotive SPICE uses generic terms: On the left side of the view, where the parts of the system are defined, ASPICE calls these portions "elements". On the right side, ASPICE names the same parts "units". These are parts of the system, eg components, ready for testing.
The explanation of purpose of integration tests totally blew my mind. Testing against architecture is something i've never heard of, are there more resources on this concept?
Hi there, the answer is right in the model: For example, SWE.5 BP3 stating “…The test specification shall be suitable to provide evidence for compliance of the integrated software items with the software architectural design.” By the way, this is true for any of the test processes: they test for compliance with their counterpart on the left side of the V. We hope this helps you!
I do not hesitate to share the Assessment overview videos with the project teams I work with. It enables directed, appropriate discussion of assessment planning, execution, and results with project teams. It also enables the discussion and training of the processes to focus more deeply on the details of the process, since the context is better understood.
As a supplier I have noticed that the fsc is never given by the OEM. Usually just vague "safety requirements" without any supporting info or rational. When I request item definitions and fsc's you usually get vague answers like "its protected by ip". For the safety of the complete system I think its critical that work products from the concept phase is given as input to the development at the system level phase. Comments?
Yes, it is normal that the OEM does not provide the FSC. It is his responsibility. And yes, the OEM must then provide (good!) functional safety requirements with ASILs allocated. The supplier does not need to know the full FSC and should however know for which item(s) his development is. And that is normally the case. We hope this helps you further!
@@KUGLERMAAGCIE Thanks for the answer. As part of the safety culture I usually insist on understanding the FSC, especially when FSR's are badly written or incomplete. Just saying "it's the OEM's responsibility" is not ok if you suspect incompleteness or incorrectness in upstream work products.
@Johnny Bravo Thank you very much for your feedback! Independence does not mean third party. As long as you comply to the independence criteria specified in part 2 of ISO 26262 that is fine. Especially in large organizations the independence criteria can be fulfilled by an other department than the developing department. We hope this helps you further!
Thanks for your question! You have to distinguish between safety goals which are the top-level safety requirements on the vehicle level and more detailed safety requirements. Here are some examples: Safety goals: - The steering column lock shall be inhibited when the vehicle is in motion. - The airbag shall not deploy unless there has been an accident. Safety requirements: - The motion of the window lift shall be stopped if the “pinch” force exceeds the defined limit. - Power assist shall be disabled if it becomes unpredictable, that is, if it causes the steering wheel to “jump” unexpectedly, or to shudder excessively in use. - The … system shall provide correct status information. These examples give you an idea of what we are talking about. We hope this helps you further! :)
How I ask the difference between feasibility and technical implication? In my opinion, feasibility might already include if a technical solution is feasible?
@Hui Jin Your assumption is correct. The check on feasibility checks on technical, but also managerial implications of a technical solutions. Please keep in mind that any doubts about the feasibility are a risk and should be tracked accordingly. We hope this answers your question!
@Bryan Kobe Depending on the market, there are further specifications such as the GSR (General Safety Regulation) for the EU. This lists the type categories accordingly. These are defined and described in further UN-ECE regulations. In case of doubt, the National Authorities are responsible for providing information. We hope this answers your question!
Test against software architecture is such amazing concept to do , it really uncovers many defects which escaped in the earlier processes. Thanks for this video :)
@youturn The SW test strategy is described as early as possible. Typically you describe a test strategy across all test levels and ensure that you cover the full functionality, account for regression testing and also address the issue how to approach testing under time constraints. The strategy should also cover entry and exit criteria, test interruption criteria, responsibilities, test environment, test coverage goals, etc. We hope that answers your question! :)
Hello Dr. Perry. this is best short video covered iso26262 HW. Do you please let me know some more example of HSR? Any reference will be helpful. Thanks in advance
@bharath great question. Here are examples of HSRs from some of our training material: • The seat sensor shall signal “unoccupied” when no object is on the seat or if object weight < 5 kg. • A stuck at closed of S2 shall be detected and a reset of both µCs shall be initiated in case of stuck at closed. • The activation signals of the ATD µC and the Safety µC for the switches shall be compared for equality and a reset shall be initiated if they are contradictory. • The comparator shall detect contradictory signal values not faster than 200 msec. • The comparator shall detect contradictory signal values latest after 600 msec. These requirements are allocated to certain parts of the hardware. We hope this helps you further!
The only thing I miss in this video is the traceability. Especially if we use statis functions or variables that are not visible in architecture, but they exists in detailed design and those functions are used by many SW elements from architecture. Could you please put some light on it? E.g. we have some function which convert from one unit to the other and it is called by several function describer in architecture or we have some statis variable to memorize variable between function calls. How to ensure the traceability to architecture in such cases?
Hi there, thanks for your feedback! We do not cover the complete process but in each the three major points. All engineering processes on system- and SW-level require traceabilities. So, even these kind of “global” functions should be traceable to SW architecture and SW detailed design. As these functions are required in several high level components, you may use a combination of references and traces. How you do that depends on your tooling and the set-up of your processes. We hope this helps you further!
Hi there! Really good video. One short question. If we test our software module in standalone framework, keeping all other modules stubbed, is it a test method as per SWE 6?
Hi there, we are not 100% sure what you refer to as “SW module”. The expectation of the SW qualification test is to test the complete software as a black box against the software requirements. Typically, this kind of test does not require the stubbing of other modules, unless your complete software is one of many modules. We hope this helps you further!
