WEBVTT 00:00:02.920 --> 00:00:10.840 Hi, I am Kai, and I am happy to announce that MXAM  12.0 is now out. As you see, no minor number, 00:00:10.840 --> 00:00:18.480 no bug fix number. A pure major release of MXAM.  And with this major release, we are introducing a 00:00:18.480 --> 00:00:26.600 new range computation feature which computes  the worst numerical range in order to detect 00:00:26.600 --> 00:00:34.920 arithmetic overflows, dead code, and design errors  on the model level. By that, supporting ISO 26262 00:00:34.920 --> 00:00:43.360 recommended design principles of strong data  typing and defensive implementation techniques. 00:00:44.520 --> 00:00:52.160 Let's have a quick look at what guidelines  are covered here. Such as the strong data 00:00:52.160 --> 00:01:00.080 typing of arithmetic blocks and, for  instance, also division in Simulink. 00:01:02.200 --> 00:01:08.000 This includes detecting errors that  may not be found by static host testing 00:01:08.000 --> 00:01:14.800 due to optimizations from the code generator. And  this range computation improves, for instance, 00:01:15.520 --> 00:01:23.840 the check for the guideline to avoid divisions  by zero in Simulink. Because the former check 00:01:24.600 --> 00:01:30.560 more or less reported review findings  on most of the divisions in the model, 00:01:31.160 --> 00:01:42.840 only considering specific modeling patterns. This  is now reduced thanks to the precise computation. 00:01:45.120 --> 00:01:49.240 Let's have a quick look here. For instance, 00:01:49.240 --> 00:02:02.720 here we see the review findings of MXAM  11.3 versus MXAM 12.0, which are now reduced 00:02:03.480 --> 00:02:11.600 thanks to the range computation,  which gives you more precise findings. 00:02:13.680 --> 00:02:26.720 Talking about precision, let's have a look at  how you can configure this. We have here this 00:02:26.720 --> 00:02:34.480 check for the overflow detection, and there  is a parameter named Computed Range Precision, 00:02:35.640 --> 00:02:44.440 where you can choose between Low, Medium, and  Maximum. This is choosing a trade-off between the 00:02:44.440 --> 00:02:52.400 precision of your computation, the reliability  of your findings, and the check runtime. 00:02:54.040 --> 00:02:56.600 Let's have a look at how this looks in practice. 00:02:59.440 --> 00:03:08.320 I had run a check here of the overflow  detection. We see here that the data range 00:03:09.520 --> 00:03:14.160 of the output is insufficient to cover  possible results of one numerical 00:03:14.760 --> 00:03:24.160 operation. And this is here the Add block.  Let's have a look where it is. There we see that 00:03:25.600 --> 00:03:32.720 the range of the output cannot cover the  whole range of this numerical operation. 00:03:34.600 --> 00:03:42.600 With every release, we have also increased our  MAB coverage, which is now nearly complete. 00:03:44.160 --> 00:03:54.920 Therefore, we also broadened our scope of  checks. Because we now have checks for guidelines 00:03:55.440 --> 00:04:03.800 that are about usable characters for data type  definitions, such as enumerations and bus signals 00:04:03.800 --> 00:04:10.440 in embedded MATLAB code, as well  as length restrictions for these. 00:04:11.800 --> 00:04:18.000 Therefore, we now have checks that  are analyzing these identifiers 00:04:18.000 --> 00:04:24.320 in embedded MATLAB code. So really a new  scope for our checks, analyzing the end code. 00:04:29.120 --> 00:04:33.440 Another small but great  addition we have in this release 00:04:34.600 --> 00:04:40.000 is regarding the use case  where we have run an analysis 00:04:40.600 --> 00:04:48.400 overnight, for instance on the CI server, and  now want to resolve guideline violations locally. 00:04:52.640 --> 00:05:02.280 Of course, the artifacts have a different  path on the CI server than they do locally. 00:05:03.680 --> 00:05:07.360 I think you can really relate to this use case. Now we want to 00:05:12.400 --> 00:05:19.160 resolve the guideline violations locally,  and then we can open the one here. 00:05:19.160 --> 00:05:24.120 Now, Continue Work mode. 00:05:27.600 --> 00:05:35.000 Now the import functionality  automatically detects that 00:05:36.200 --> 00:05:43.360 this model is on a different path.  So we can open it here manually. 00:05:56.480 --> 00:06:12.400 And then proceed with working  on the guideline violations. 00:06:20.200 --> 00:06:27.200 Another great addition in this  major release of MXAM 12.0 00:06:28.120 --> 00:06:36.480 is the automated migration of projects.  I think, as an engineer, you may relate 00:06:37.240 --> 00:06:45.240 to the fact that manual migration with  different error-prone steps is not really the 00:06:45.240 --> 00:06:53.080 way you want to spend your time. Instead, you  really want to focus on working with MXAM. 00:06:53.640 --> 00:07:01.480 This is why this major release helps you  with migrating projects from older releases. 00:07:03.000 --> 00:07:12.440 Let's have a look here. We want to load a project,  this one, which is coming from an older release. 00:07:15.040 --> 00:07:24.840 When we load this here, you get a report  showing what has been done. First of all, we see 00:07:24.840 --> 00:07:29.720 that the guideline document should be  updated. We will have a look at this. 00:07:30.360 --> 00:07:35.200 Then we see that the project was  aligned with the updated content, 00:07:35.960 --> 00:07:41.000 which means, for instance, that there are  some changes in the guideline selection. 00:07:42.040 --> 00:07:47.520 As you know, between releases,  we are always updating checks 00:07:48.960 --> 00:07:56.040 and adding new checks. For instance, for this  guideline, one of the changes between the release 00:07:56.040 --> 00:08:01.240 the project was created with and the current  release is that we added this check, which is 00:08:01.240 --> 00:08:07.360 now automatically selected because the guideline  was already selected in the project guidelines. 00:08:08.400 --> 00:08:15.880 Also interesting, we see here that one  parameter setting has also been migrated, 00:08:16.760 --> 00:08:20.720 which was defined here for this check. 00:08:22.720 --> 00:08:29.360 Now let's have a look at what we can  do regarding the updated document. 00:08:32.440 --> 00:08:37.520 We have here the project  guidelines, and now we can 00:08:40.200 --> 00:08:47.360 update this guideline document, which  was one of the features of MXAM 11.3. 00:08:48.560 --> 00:08:56.160 Also with this major release, the  MISRA AC SLSF (2009) document is gone, since 00:08:57.360 --> 00:09:08.120 it is now deprecated. Instead, we have  the latest document, MISRA AC SLSF:2023 . 00:09:10.120 --> 00:09:15.040 We can now go ahead as usual and update everything 00:09:17.280 --> 00:09:26.440 so that we also have a document which  complies with the updated content of MXAM. 00:09:29.920 --> 00:09:36.720 As with most software tools, especially  in specific fields, there are several 00:09:36.720 --> 00:09:46.280 tools on the market. This is also the case for  static testing of models. In order to ease the 00:09:46.840 --> 00:10:00.200 migration, we have added the feature to import  configurations directly from Model Advisor, 00:10:00.800 --> 00:10:06.720 really to smooth the process of  moving from Model Advisor to MXAM. 00:10:07.920 --> 00:10:15.000 This is how you can do it.  By creating a new project, 00:10:17.760 --> 00:10:28.000 here below the MXAM Project, you can create  an MXAM project from a Model Advisor project. 00:10:30.840 --> 00:10:38.160 You can go ahead here and choose  the Model Advisor project, 00:10:40.360 --> 00:10:48.400 which is available as a JSON file, and  import and convert it into an MXAM project. 00:10:50.160 --> 00:10:53.720 Another improvement of this major release 00:10:54.480 --> 00:11:01.920 is the handling of reusable elements  in Simulink together with MXAM. 00:11:03.360 --> 00:11:09.520 As a background, as you know, there are several  reusable components available in Simulink, 00:11:09.520 --> 00:11:18.720 depending on the use case. We have the virtual  subsystem, we have blocks with library links, 00:11:19.440 --> 00:11:24.480 as well as references to a  subsystem or a model, respectively. 00:11:25.280 --> 00:11:31.200 Now, with MXAM 12.0, there comes  an improvement for this use case. 00:11:32.440 --> 00:11:38.160 You can now repair elements  that are in linked libraries. 00:11:39.960 --> 00:11:41.600 Let's have a look at this. 00:11:43.640 --> 00:11:53.040 First of all, we have an addition in the report.  You see here that we now have a Reference Path 00:11:53.040 --> 00:11:57.960 property and a Reference Name,  so that you can clearly see 00:11:59.040 --> 00:12:05.000 if this element is part of a  subsystem with a library link. 00:12:06.520 --> 00:12:14.720 Now let's have a look here. We have a finding on  a Constant, which is about the Show Block 00:12:14.720 --> 00:12:24.320 Name parameter being set to off, which should be  set to on. We see here the link to the library. 00:12:25.680 --> 00:12:35.160 The library is called Gain Add, and with  MXAM 12.0, you are now able to repair this. 00:12:36.080 --> 00:12:47.440 Let's do a quick split screen and repair both  of the findings here. We set Show Name to on. 00:12:57.080 --> 00:13:00.120 Here's another indicator in the repair dialog 00:13:00.120 --> 00:13:04.320 that this element is in the Gain Add  library, so that you can clearly see 00:13:05.120 --> 00:13:15.000 that you are repairing an element that is part  of a library. Depending on your process, you may 00:13:15.000 --> 00:13:20.800 not be allowed to do that, but this makes it very  clear that you are repairing a library element. 00:13:24.280 --> 00:13:28.320 For this showcase, we want to apply it here. 00:13:36.600 --> 00:13:44.600 Then we see it here in the Findings per Check  view. We see both repairs, and we also see that we 00:13:44.600 --> 00:13:53.200 still have the findings for the Gain and Constant also for the other references of this library. 00:13:55.640 --> 00:14:03.720 Since we repaired them in the  library, we can simply do a rerun here 00:14:05.720 --> 00:14:14.840 and would now expect that both  findings are going to be removed. 00:14:14.840 --> 00:14:28.800 As you can see, with this one repair of the  library, every instance is now repaired, and we 00:14:31.200 --> 00:14:35.640 resolved six findings of this guideline. 00:14:35.640 --> 00:14:38.640 Let's do another example with another guideline. 00:14:41.720 --> 00:14:48.520 We see here a finding for the Gain block,  which is about the rounding mode, where we have 00:14:50.120 --> 00:14:54.080 the Floor rounding mode set.  The same goes for the Sum. 00:14:54.080 --> 00:15:06.560 As we already know, we have several instances  in this model. Here we have one Gain Add, and 00:15:08.080 --> 00:15:16.240 above we have other links to the  same library. We see that we have 00:15:17.800 --> 00:15:23.320 the finding for the Gain and Sum here, and the same findings here as well. 00:15:23.320 --> 00:15:28.440 That means, again, to resolve the  violations for the library, let's 00:15:32.480 --> 00:15:36.640 repair both findings by setting  the rounding method to Zero. 00:15:37.800 --> 00:15:39.920 We can simply click Apply All. 00:15:45.560 --> 00:15:58.440 Now we see that both are repaired, and we would now expect that these findings would also pass after the rerun. 00:16:04.720 --> 00:16:14.280 This feature of repairing linked  elements really speeds up the process of 00:16:15.080 --> 00:16:21.880 automatically repairing guideline  violations with MXAM in use cases 00:16:21.880 --> 00:16:26.800 where you are using reusable  components such as libraries.