{"id":4215,"date":"2020-04-08T09:28:09","date_gmt":"2020-04-08T07:28:09","guid":{"rendered":"https:\/\/zen-cori.138-201-132-86.plesk.page\/?p=4215"},"modified":"2023-02-06T12:40:37","modified_gmt":"2023-02-06T10:40:37","slug":"4-ways-to-detect-undesired-changes-during-a-tool-version-migration","status":"publish","type":"post","link":"https:\/\/www.btc-embedded.com\/de\/4-ways-to-detect-undesired-changes-during-a-tool-version-migration\/","title":{"rendered":"4 Ways to Detect Undesired Changes During a Tool Version Migration"},"content":{"rendered":"\t\t<div data-elementor-type=\"wp-post\" data-elementor-id=\"4215\" class=\"elementor elementor-4215\" data-elementor-post-type=\"post\">\n\t\t\t\t\t\t<section class=\"elementor-section elementor-top-section elementor-element elementor-element-3b5f0493 elementor-section-boxed elementor-section-height-default elementor-section-height-default\" data-id=\"3b5f0493\" data-element_type=\"section\">\n\t\t\t\t\t\t<div class=\"elementor-container elementor-column-gap-default\">\n\t\t\t\t\t<div class=\"elementor-column elementor-col-100 elementor-top-column elementor-element elementor-element-559a247a\" data-id=\"559a247a\" data-element_type=\"column\">\n\t\t\t<div class=\"elementor-widget-wrap elementor-element-populated\">\n\t\t\t\t\t\t<div class=\"elementor-element elementor-element-fed356d elementor-widget elementor-widget-text-editor\" data-id=\"fed356d\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<h3>4) Software Requirements in ISO 26262 chapter 6<\/h3><p>Software requirements are the result of a transformation process of the TSRs allocated to software parts and the HSIs into a set of requirements used to develop the software functions. In parallel, hardware requirements are also derived to develop the hardware elements. Software requirements describe the static and dynamic aspects of the software elements. The software elements are software components, software units and software interfaces identified during the software architectural design phase. The transformation process typically results into 3 categories of software requirements:<\/p><ul><li><b>Software architecture requirements<\/b>\u00a0describe the structure and relationships of the software components and contribute to create the software architecture. The software architecture serves as a backbone for the implementation of the software requirements. They can also express constraints about performance and robustness of a software element (sometimes called non-functional requirements).<\/li><\/ul><p>Note: In order to manage the architecture complexity and hence meet the safety requirements, ISO 26262 recommends architecture design principles such as abstraction, modularity, encapsulation, hierarchical structure, cohesion within software components, etc. For this purpose, a suitable notation must be used. The experience has shown that the\u00a0<a href=\"https:\/\/www.btc-es.de\/en\/blog\/autosar-what-every-function-developer-should-know.html\" target=\"_blank\" rel=\"noopener\">AUTOSAR architecture standard<\/a>\u00a0is a good candidate to fulfil the ISO requirements as it supports most of them.<\/p><ul><li><b>Software safety requirements<\/b>\u00a0focus on the safety-related functionalities to satisfy the technical safety requirements and avoid critical system situations which may lead to hazards or serious faults. (E.g.: safe execution of a nominal function, maintaining a safe state, detecting indicating and mitigating potential faults, management of time-critical operations and fault tolerances, etc.)<\/li><\/ul><ul><li><b>Software requirements<\/b>\u00a0specify the non-safety software functions and are derived from the intended functions for which the HARA analysis resulted in a no ASIL rating (QM requirements).<\/li><\/ul><p>Both safety and non-safety requirements are functional (behavioral) requirements. They describe the capabilities of the software element to act in its operating situations and express a specific reaction to a certain input stimulus. Each of these requirements needs to refer to a software component or unit and to one or multiple software interfaces defined in the software architecture.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-d83c847 elementor-widget elementor-widget-text-editor\" data-id=\"d83c847\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>There are many reasons for migrating to newer tool versions. IT departments keeping an eye on security might force\u00a0you to move away from versions that are no longer supported (e.g. Windows 7). At the same time the ability to produce the right code \/ better code will motivate you to move to newer versions, e.g. based on features like:<\/p><ul><li>New AUTOSAR versions<\/li><li>Improved enumeration handling<\/li><li>The latest or better code optimization algorithms<\/li><\/ul><p>Also improvements that impact the everyday life of developers and testers with new features in interactive workflows are a strong factor, e.g.:<\/p><ul><li>New TargetLink Property Manager<\/li><li>Quick-Insert for library blocks in Simulink, etc.<\/li><\/ul><p>In the end, motivated individuals produce the best results.<\/p><p>The reason why a lot of teams are stuck with outdated software versions is the &#8222;If it ain&#8217;t broke, don&#8217;t fix it&#8220; fear. Indeed, moving to a different version of a tool that plays an integral role in your software development &#8211; or even swapping to a different tool, e.g. replacing a VisualStudio compiler with MinGW &#8211; involves the risk of accidentally changing the behavior of your software. This kind of undetected change would lead to painful regressions that are immensely difficultto trace back and resolve, and would increase in complexity the later they are found in the process.<\/p><p>What we need is a way to immediately detect changes introduced by a migration in order to prevent a roll-out with undesired behavior. In the following sections I will show the migration of a model to new versions of Matlab, TargetLink and Windows. Based on this example we will explore different approaches to\u00a0make sure changes get detected and automate the resulting workflow with Jenkins.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-7c099a8 elementor-widget elementor-widget-heading\" data-id=\"7c099a8\" data-element_type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\">Migrating a Module<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-a1ff07f elementor-widget elementor-widget-text-editor\" data-id=\"a1ff07f\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>Let&#8217;s migrate our example module from ML 2015b \/ TL4.1 on Windows 7 to ML2018b TL4.4 on Windows 10. I will copy my old model to another folder, open it on Windows 10 with Matlab 2018b and let Matlab and TargetLink perform the needed data conversion steps automatically. We now have a migrated model. Easy enough, right? The only thing that&#8217;s left to do is to somehow check for undesired changes.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-19ece90 elementor-widget elementor-widget-image\" data-id=\"19ece90\" data-element_type=\"widget\" data-widget_type=\"image.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<img fetchpriority=\"high\" decoding=\"async\" width=\"800\" height=\"71\" src=\"https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2020\/04\/Bildschirmfoto-2022-06-30-um-09.30.45.png\" class=\"attachment-large size-large wp-image-4219\" alt=\"\" srcset=\"https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2020\/04\/Bildschirmfoto-2022-06-30-um-09.30.45.png 1806w, https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2020\/04\/Bildschirmfoto-2022-06-30-um-09.30.45-768x68.png 768w, https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2020\/04\/Bildschirmfoto-2022-06-30-um-09.30.45-1536x136.png 1536w\" sizes=\"(max-width: 800px) 100vw, 800px\" \/>\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-27e953f elementor-widget elementor-widget-heading\" data-id=\"27e953f\" data-element_type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\">Exploring ways to detect undesired changes<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-51d2a0f elementor-widget elementor-widget-heading\" data-id=\"51d2a0f\" data-element_type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\">Approach 1: Compare the C-Files<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-0c6dd31 elementor-widget elementor-widget-text-editor\" data-id=\"0c6dd31\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>We can actually save a lot of time and effort if we can show that the code from the old model and the new migrated model are the same. Let&#8217;s generate code from our migrated model, then grab the C files containing the main step function (original &amp; migrated) and throw them into Beyond Compare:<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-f72eab6 elementor-widget elementor-widget-image\" data-id=\"f72eab6\" data-element_type=\"widget\" data-widget_type=\"image.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<img decoding=\"async\" width=\"800\" height=\"462\" src=\"https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2020\/04\/beyond-compare-1920x1920-40e.png\" class=\"attachment-large size-large wp-image-4222\" alt=\"\" srcset=\"https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2020\/04\/beyond-compare-1920x1920-40e.png 1284w, https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2020\/04\/beyond-compare-1920x1920-40e-768x444.png 768w\" sizes=\"(max-width: 800px) 100vw, 800px\" \/>\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-95f5f80 elementor-widget elementor-widget-text-editor\" data-id=\"95f5f80\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>Comparing the c-files of the old and new configuration<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-fa217fc elementor-widget elementor-widget-text-editor\" data-id=\"fa217fc\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>Even after a lot of tweaks that ignore comments, whitespace changes, etc. we&#8217;re still stuck with 16 difference sections, and even different variable sizes are being used. That&#8217;s surprising since I didn&#8217;t change the model&#8230; It seems we can forget our awesome idea to check for changes by simply comparing the code. And come to think of it, we can&#8217;t and shouldn&#8217;t expect the code to be the same. We&#8217;re using a Code Generator and we expect each new version of the code generator to improve the code optimization.\u00a0We also would not expect to get the exact same object code if we change a compiler version.<\/p><p>So let&#8217;s accept that the code looks a bit differently. But hopefully it still behaves in the same way&#8230; so what can we do to check that?<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-7303e71 elementor-widget elementor-widget-heading\" data-id=\"7303e71\" data-element_type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\">Approach 2: Re-Run Functional Tests<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-79c29f9 elementor-widget elementor-widget-text-editor\" data-id=\"79c29f9\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>Naturally we want the migrated module to meet our requirements just like our original module. So why don&#8217;t we set up a test project for the migrated module and import the existing test cases that we have. Those were written based on the requirements for our module and check the appropriate behavior. Creating the test project is fairly simple, we just point to the model and let our test tool take over from there. After importing our existing test cases we run them and check the results:<\/p><p>Awesome! All of our tests are still passing on the migrated module. However, if we take a closer look into the test case, the concept of using our requirements-based tests to ensure the migration shows a weakness:<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-268539f elementor-widget elementor-widget-image\" data-id=\"268539f\" data-element_type=\"widget\" data-widget_type=\"image.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<img decoding=\"async\" width=\"766\" height=\"371\" src=\"https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2020\/04\/test_case_detail-1920x1920-a33.png\" class=\"attachment-large size-large wp-image-4225\" alt=\"\" \/>\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-ef2476b elementor-widget elementor-widget-text-editor\" data-id=\"ef2476b\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>The test case was designed to check if a particular part of our system under test reacts correctly to a specific situation. This leaves a lot of room for deviation. Even if our module still meets the requirements, we don&#8217;t want to miss any changes in its behavior. Naturally, a requirements-based test case does not check the exact value of every signal in every step of the execution, that would be pretty inefficient. After all, that&#8217;s not what a requirements-based test is supposed to do thus we cannot only rely on passed test cases when checking the impact of the migration. I guess we need yet another approach that takes this into account.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-46ac4dd elementor-widget elementor-widget-heading\" data-id=\"46ac4dd\" data-element_type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\">Approach 3: Regression Test with Functional Tests<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-190a8e8 elementor-widget elementor-widget-text-editor\" data-id=\"190a8e8\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>This is where the concept of a structural regression test comes in handy. It does exactly what our last approach was missing: it compares\u00a0all\u00a0signals in\u00a0all\u00a0steps of the executions. In our scenario we would compare the executions of the original module with those of the migrated module: ML2015b\/TL4.1 vs. ML2018b\/TL4.4. The expected behavior defined in our test cases doesn&#8217;t play a role here anymore since the structural regression test is &#8211; indeed &#8211; structural. It doesn&#8217;t check if the system under test behaves &#8222;correctly&#8220;. The goal of the structural regression test is to check if both versions of the system under test behave exactly the same. We can easily do this with the following steps:<\/p><ol><li>Simulate test cases in the old test project (based on the original module)<\/li><li>Export the execution records<\/li><li>Import them into the new test project (based on the migrated module)<\/li><li>Run the Regression Test<\/li><\/ol><p>The Regression Test passed showing us that the behavior of the migrated module doesn&#8217;t show the slightest deviation. Looking back at the previous approach we now compared each signal in every step.<\/p><p>We&#8217;ve come close to a solid solution but looking at the coverage we can see that we still have a problem:<\/p><p>No matter how desirable it is, most projects don&#8217;t reach 100% MC\/DC with requirements-based tests. We now know that our migrated module behaves the same for the set of test cases we used but obviously there is plenty of uncovered code left for which we don&#8217;t know this. We still cannot say with confidence that the migration was successful.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-9a9f5a0 elementor-widget elementor-widget-heading\" data-id=\"9a9f5a0\" data-element_type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\">Approach 4: Regression Test with 100% Coverage<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-be1858c elementor-widget elementor-widget-text-editor\" data-id=\"be1858c\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>One option would be to write additional test cases. Having high coverage from requirements-based tests is desirable after all. However, in real production projects the effort of getting to 100% coverage is often not accepted. Luckily we can automatically generate stimuli vectors for this purpose that bring us to full coverage. A stimuli vector is similar to a test case but it only contains values for inputs and calibrations, no expected behavior is defined. As explained above though, the Regression Test is structural. The expected values for the regression test come from the reference simulation and in the end we want to show that the migrated module behaves the same.<\/p><p>The resulting workflow enables a complete comparison (all signals in every step with full coverage) and looks like this:<\/p><ol><li>creating a test project for the original module<\/li><li>importing existing test cases (optional)<\/li><li>generating additional stimuli vectors for 100% coverage<\/li><li>performing a reference simulation<\/li><li>exporting the execution records for the regression test<\/li><li>creating a test project for the migrated module<\/li><li>importing the execution records from the original module<\/li><li>performing the regression test: original module vs. migrated module<\/li><\/ol>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-46bd8d4 elementor-widget elementor-widget-heading\" data-id=\"46bd8d4\" data-element_type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\">Automating our Workflow with Jenkins<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-debc5f5 elementor-widget elementor-widget-text-editor\" data-id=\"debc5f5\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>Now that we&#8217;ve come up with a suitable workflow to prevent undesired changes during the migration, let&#8217;s prepare a fully automated workflow in Jenkins. We will set up a\u00a0<em>Jenkins Pipeline<\/em>\u00a0which embraces the concept of\u00a0<em>Configuration as Code<\/em>\u00a0by specifying what Jenkins needs to know about a workflow in a so-called Jenkinsfile. This is important because with the increasing importance of automation in today&#8217;s software development the configuration of automated workflows is just as crucial as the code itself.<\/p><p>The files we&#8217;re using for this example are stored in a Github repository but the procedure is the same even when you&#8217;re using another source code management system. In the Jenkins web interface, we&#8217;ll create a new Pipeline job from scratch (New Item &gt; Pipeline). The only thing we need to configure is the URL that points to the repository containing our files. When running the Pipeline job, the Jenkins Master will first grab the Jenkinsfile from the root of our repository and parse it. This way, Jenkins knows exactly what steps to perform and what kinds of Jenkins Agent machines are suitable for the task. All we need for our migration test workflow are two steps:<\/p><p><strong>Step1: The Reference<br \/><\/strong><\/p><p>In this step we perform all required tasks on the original module:<\/p><ul><li>(1) creating a test project for the original module<\/li><li>(2) importing existing test cases (optional)<\/li><li>(3) generating additional stimuli vectors for 100% coverage<\/li><li>(4) performing a reference simulation<\/li><li>(5) exporting the execution records for the regression test<\/li><\/ul><p><strong><br \/>Step 2: The Comparison<br \/><\/strong><\/p><p>In this step we perform all required tasks on the migrated module:<\/p><ul><li>(6) creating a test project for the migrated module<\/li><li>(7) importing the execution records from the original module<\/li><li>(8) performing the regression test: original module vs. migrated module<\/li><\/ul><p>A passed result based on this workflow let&#8217;s us say with the confidence that the migration did not introduce any changes in our module. If it does, we will know immediately and have test cases that we can use for debugging.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-91ba293 elementor-widget elementor-widget-heading\" data-id=\"91ba293\" data-element_type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\">Summary<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-5aba506 elementor-widget elementor-widget-text-editor\" data-id=\"5aba506\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>We started off with the need to migrate to newer tool versions or even change some of the tools involved in our software build process. At the same time, if the migration introduced undesired behavior, we want to see this right away and not notice it weeks or months later when the tool migrations has already been deemed successful. Trust me, coming from a DevOps background I know that having to roll back to some years older tool versions after a while causes a lot of mayhem.<\/p><p>Thus, we explored different approaches to detect undesired changes right away. These are lessons learned:<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-097fa8d elementor-widget elementor-widget-image\" data-id=\"097fa8d\" data-element_type=\"widget\" data-widget_type=\"image.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<img loading=\"lazy\" decoding=\"async\" width=\"800\" height=\"498\" src=\"https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2022\/05\/Blog_4ways_Tab1.png\" class=\"attachment-large size-large wp-image-4641\" alt=\"\" srcset=\"https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2022\/05\/Blog_4ways_Tab1.png 3235w, https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2022\/05\/Blog_4ways_Tab1-768x478.png 768w, https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2022\/05\/Blog_4ways_Tab1-1536x955.png 1536w, https:\/\/www.btc-embedded.com\/wp-content\/uploads\/2022\/05\/Blog_4ways_Tab1-2048x1274.png 2048w\" sizes=\"(max-width: 800px) 100vw, 800px\" \/>\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-d0d53dd elementor-widget elementor-widget-text-editor\" data-id=\"d0d53dd\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>Ultimately, when we&#8217;re faced with\u00a0a big number of complex tasks with high risk that we&#8217;re afraid of and that keep us awake at night, my advice is the following:<\/p><ol><li>Understand it<\/li><li>Automate it<\/li><li>Make good use of it<\/li><\/ol><p>Making good use of an automated workflow increases your confidence in it allowing you to sleep like a baby.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-3edd05c elementor-widget elementor-widget-heading\" data-id=\"3edd05c\" data-element_type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\">Want to see more?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-ece022a elementor-widget elementor-widget-text-editor\" data-id=\"ece022a\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>Check out our\u00a0<a href=\"https:\/\/www.btc-es.de\/en\/news\/events\/webinar-4-strategies-to-upgrade-to-a-new-matlabsimulink-version.html\" target=\"_blank\" rel=\"noopener\">Live Webinar<\/a>\u00a0in which we demonstrate all 4 approaches.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"<p>4) Software Requirements in ISO 26262 chapter 6 Software requirements are the result of a transformation process of the TSRs allocated to software parts and the HSIs into a set of requirements used to develop the software functions. In parallel, hardware requirements are also derived to develop the hardware elements. Software requirements describe the static [&hellip;]<\/p>\n","protected":false},"author":7,"featured_media":9050,"comment_status":"open","ping_status":"closed","sticky":false,"template":"elementor_theme","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[55,56,54,49,48,51],"product":[],"use_cases":[],"class_list":["post-4215","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-ci-cd","tag-cloud","tag-jenkins","tag-model-based-development","tag-simulink","tag-targetlink"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.btc-embedded.com\/de\/wp-json\/wp\/v2\/posts\/4215","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.btc-embedded.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.btc-embedded.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.btc-embedded.com\/de\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/www.btc-embedded.com\/de\/wp-json\/wp\/v2\/comments?post=4215"}],"version-history":[{"count":0,"href":"https:\/\/www.btc-embedded.com\/de\/wp-json\/wp\/v2\/posts\/4215\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.btc-embedded.com\/de\/wp-json\/wp\/v2\/media\/9050"}],"wp:attachment":[{"href":"https:\/\/www.btc-embedded.com\/de\/wp-json\/wp\/v2\/media?parent=4215"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.btc-embedded.com\/de\/wp-json\/wp\/v2\/categories?post=4215"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.btc-embedded.com\/de\/wp-json\/wp\/v2\/tags?post=4215"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/www.btc-embedded.com\/de\/wp-json\/wp\/v2\/product?post=4215"},{"taxonomy":"use_cases","embeddable":true,"href":"https:\/\/www.btc-embedded.com\/de\/wp-json\/wp\/v2\/use_cases?post=4215"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}