![KUGLER MAAG CIE by UL Solutions](/img/default-banner.jpg)
- 63
- 4 365 387
KUGLER MAAG CIE by UL Solutions
Germany
Приєднався 5 бер 2020
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.
www.kuglermaag.com/impress.html
With this channel, we provide knowledge and first-hand insights to Automotive engineering practitioners.
www.kuglermaag.com/impress.html
IT Service Management (ITSM) for the Software-Defined Vehicle | Introducing SPICE for IT Services
Managing quality for the Software-Defined Vehicle involves aspects both inside and outside the vehicle. Quality will come from seamless and uninterrupted interaction between the components of services. For this, IT Service Management coordinates digital services from end to end, throughout the vehicle lifecycle and even beyond.
This video is also on the application of ITSM in the automotive industry with the evolving process model SPICE for IT Services.
This video is also on the application of ITSM in the automotive industry with the evolving process model SPICE for IT Services.
Переглядів: 215
Відео
Automotive Cybersecurity: Regulations and standards
Переглядів 1,6 тис.5 місяців тому
Are you wondering what you need to do to comply with international regulations on cybersecurity - and how these standards can help you achieve a high level of cybersecurity? In this video, we will explore the complex regulatory framework for cybersecurity governing the automotive industry. For more detailed information you can download this white paper for free: www.kuglermaag.com/automotive-cy...
Automotive SPICE V4.0 - The new intacs™ training concept
Переглядів 9118 місяців тому
What is Automotive SPICE for? The model ensures quality in the development of automotive electronics. It supports developers of software-centric systems as well as engineers who create mechatronic systems. Learn more on the recently released version v4.0 of Automotive SPICE here: kuglermaag.com/aspice4 In this video, we would like to introduce you to the new intacs training concept on Automotiv...
Machine Learning Engineering | Learn more about The Process Model in Automotive SPICE v4.0
Переглядів 6 тис.8 місяців тому
Innovative functions are realized via software, which often implements software artifacts created using Machine Learning. In this video, you will learn how to reliably and safely integrate machine learning into your product development. Do you want to have more detailed information? Download our free white paper now: www.kuglermaag.com/automotive-spice/machine-learning/ You want to increase you...
Automotive SPICE 4.0 - The key changes
Переглядів 6 тис.10 місяців тому
Automotive SPICE 4.0 is coming and you're unaware of the upcoming changes? Then you've come to the right place! Allow us to support you as experts in Automotive SPICE®. We’ll provide you with professional and practical support: From advisory services to preparation, process improvements, and even training and assessments: www.kuglermaag.com/automotive-spice/ The experts of Kugler Maag Cie by UL...
Automotive SPICE 4.0: What's new?
Переглядів 19 тис.Рік тому
Version 4.0 of Automotive SPICE will be released in the fall of 2023. In this video, we show you what changes this will mean for the processes in your development team! You want to have more detailed information and exchange with experts? Join one of our free one-day events: www.kuglermaag.com/training-automotive-spice/update-aspice-v40/ The experts of Kugler Maag Cie by UL Solutions provide th...
Software Update Management System (SUMS) | Automotive Cybersecurity
Переглядів 8 тис.Рік тому
Your Software Update Management System (SUMS) is what makes your cybersecurity activities effective: because software updates are the remedy to counter threats from cyberspace. With SUMS, you can handle these updates in compliance with regulatory requirements. For more detailed information you can download this white paper for free: www.kuglermaag.com/automotive-cybersecurity/software-update-ma...
Automotive SPICE Assessments - Part 3: What is an ASPICE Assessment? | Engineering Expertise E/E #07
Переглядів 2 тис.Рік тому
This is the third video of our series about Automotive SPICE Assessments! In this video, you learn everything about how to prepare an ASPICE assessment. 🎓 If you want to learn more about Automotive SPICE and become a process improvement expert, check out our trainings: www.kuglermaag.com/training-automotive-spice/ This is your channel if you need knowledge on process improvement topics: Automot...
Configuration Management (SUP.8) - Automotive SPICE
Переглядів 6 тис.Рік тому
Configuration management is one of the most important core processes of Automotive SPICE. It allows you to manage how you can decouple customer-specific releases in the regular day-to-day R&D, while still maintaining transparency over the development project. In this video, we give you a quick overview and the most important aspects of this Automotive SPICE process. For more detailed informatio...
Functional Safety Concepts (FSC) - ISO 26262 | Engineering Expertise EE #06
Переглядів 9 тис.Рік тому
After hazard analysis and risk assessment, the Functional Safety Concept (FSC) is the next logical step in controlling faults in automotive electronic systems. In this video, we will explain: - What the Functional Safety Concept is - What it must specify - The creation process of the Functional Safety Concept For more detailed information you can download the white paper here for free: www.kugl...
Automotive SPICE Assessments - Part 2: What is an ASPICE Assessment | Engineering Expertise E/E #05
Переглядів 2,3 тис.Рік тому
Automotive SPICE Assessments - Part 2: What is an ASPICE Assessment | Engineering Expertise E/E #05
Automotive Cybersecurity - Over simplified
Переглядів 1,8 млнРік тому
Automotive Cybersecurity - Over simplified
Hazard Analysis and Risk Assessment (HARA) | Engineering Expertise EE#4
Переглядів 12 тис.Рік тому
Hazard Analysis and Risk Assessment (HARA) | Engineering Expertise EE#4
Training: Automotive SPICE Provisional Assessor
Переглядів 1,6 тис.Рік тому
Training: Automotive SPICE Provisional Assessor
Training Recommendation: Automotive Security 2-in-1 Course
Переглядів 650Рік тому
Training Recommendation: Automotive Security 2-in-1 Course
Automotive SPICE Assessments - Part 1: What is an ASPICE Assessment | Engineering Expertise E/E #03
Переглядів 9 тис.Рік тому
Automotive SPICE Assessments - Part 1: What is an ASPICE Assessment | Engineering Expertise E/E #03
Automotive Cybersecurity Engineering - What's that?
Переглядів 192 тис.2 роки тому
Automotive Cybersecurity Engineering - What's that?
Training: TÜV Nord Automotive Cybersecurity Engineer | Kugler Maag Cie
Переглядів 1,1 тис.2 роки тому
Training: TÜV Nord Automotive Cybersecurity Engineer | Kugler Maag Cie
Functional Safety Assessments (FSA acc. ISO 26262) | Engineering Expertise E/E #02
Переглядів 4 тис.2 роки тому
Functional Safety Assessments (FSA acc. ISO 26262) | Engineering Expertise E/E #02
Cybersecurity and UNECE - Over simplified
Переглядів 39 тис.2 роки тому
Cybersecurity and UNECE - Over simplified
Automotive Cybersecurity: TARA in Practice | Training
Переглядів 2,6 тис.2 роки тому
Automotive Cybersecurity: TARA in Practice | Training
Automotive Cybersecurity Engineering Training Program
Переглядів 28 тис.2 роки тому
Automotive Cybersecurity Engineering Training Program
Functional Safety and Cybersecurity Touchpoints | Engineering Expertise E/E #01
Переглядів 5 тис.2 роки тому
Functional Safety and Cybersecurity Touchpoints | Engineering Expertise E/E #01
SYS.5 System Qualification Test | Automotive SPICE
Переглядів 11 тис.2 роки тому
SYS.5 System Qualification Test | Automotive SPICE
Automotive SPICE for Cybersecurity - Training Course
Переглядів 1,9 тис.2 роки тому
Automotive SPICE for Cybersecurity - Training Course
SWE.5 Software Integration and Integration Test | Automotive SPICE
Переглядів 18 тис.2 роки тому
SWE.5 Software Integration and Integration Test | Automotive SPICE
Cybersecurity Management System - Part II
Переглядів 7 тис.2 роки тому
Cybersecurity Management System - Part II
Cybersecurity Management System - Part I
Переглядів 7 тис.2 роки тому
Cybersecurity Management System - Part I
nice!
We're glad you like it! :)
Great Learning Experience
Thank you for your feedback, we're very happy to hear that :)
This video is very good at all levels. Kudos!
Thank you so much, we're glad you like it!
hello There, Thanks for the great video, which video do you suggest to watch for more detail info's on Part 7 ?
You're very welcome! Good news - the video for Part 7 is already in our production pipeline. Stay tuned :)
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 ?
Thank you very much for your feedback. We will take it into consideration for future videos!
It is not clear who should do the SWE.4 based on your experience
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!
Why your website is not working, the web page cant be see , there is any problem
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!
WATCHING FROM INDIA MA'AM
You're very welcome.
Properly followed sir
😊😊
ک😊ف
Great Job!! Thanks a lot
We're glad that you like it :)
Good presentation for understanding of ASPICE for cybersecurity in high level
Thank you for your feedback :)
Is the safety analysis a part of the SW architecture?
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!
Dieses Video gibt einen umfassenden Einblick in die Thematik und stellt drei Punkte in den Fokus. Sehr informativ für Menschen im Automotive Kontext.
Vielen Dank, dann haben wir unser Ziel erreicht.
Much respect ❣️
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!
Nice summary. Thanks. Can I have the presentation please?
Is unit a. Single function? Actually not so clear whats unit and sw test differences
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.
very profound and clear lecture professor
We're glad you like it!
Also loved the traceability concept! thanks for such a great learning experience
Thank you very much for your feedback :)
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!
Wonderful explanation i became a fan of this channel now❤
Thank you so much - we're glad that you're now a part of our community! :)
I'm the first one 😎😎😅... thank you so much for an educational content
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.
Great presentation! Thanks for sharing. I have one question, does the independent confirmation requires mandatory involvement of third parties?
@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!
@@KUGLERMAAGCIE Thank you very much. So the requirements are similar to that of IEC 61508.
Nice effort
Great tutorial on basics of an assessment in automotive industry. Don't miss part II!
Thank you so much for the call! And for sure you shouldn't miss Part II: ua-cam.com/video/Ud7_ST49Ric/v-deo.html.
Thanks Erwin. Great videos!
We're glad to hear that you like our videos! :)
Bravo
Thank you for your feedback! :)
Thanks for this great set of videos. Appreciate the hard work involved.
We're glad that you like it - thanks a lot for your feedback!
Can I get more idea on formulation of safety goals with functional safety requirements
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! :)
Perfect
Thank you so much!
Great presentation, thanks!
You're very welcome :)
Hello Sir, Thanks for the explanation level which can understand by beginners also... kindly put more videos for Random Hardware Failure sir👍
Thanks for the great feedback, we appreciate it!
Thank you soo might for this sharing!!!
You're welcome! :)
Good video!
We're glad that you like it! :)
Thank you so much!! Very helpful!
We're glad to hear that! :)
Thanks for the detailed explanation sir👌🏻
@Siva Kumar Surala you're very welcome! :)
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!
Does this Regulation also count for accessories? For example a trailer module?
@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 :)
Thank you very much for your feedback :)
Very neatly explained. One question was regarding Traceability - is traceability matrices or matresses? the sub titles showed matresses.
@vishrut kumar Thank you very much for pointing this out - it was a typo which has been corrected in the meantime! :)
when i need to write the SW Test strategy? Immediately after SW requirements analysis or after coding and Unit verification?
@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!
@@KUGLERMAAGCIE . Perfect! Thanks for the reply.
Heartful thanks for your presentation.. keep posting more on the cybersecurity topics
Thank you very much, we're already working on the next cybersecurity video. Subscribe to our channel to not miss the upcoming video :)
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!
Excellent summary of TARA. Thank you
Thank you very much! :)
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!
Very useful, thanks. Just an observation: at 09:01 "defective" was written "detective" by mistake
Thank you for pointing it out! :)
Fantastic video. Perfect example of a easy to follow video with solid information and eye catching graphics.
We're glad that you like it :)