So, when you do the coverage and you need to document it, well, then it better to export it, and document it really somehow. So, what we have is that our data can be transformed, so t32transform.xsl, and so we can transform all collected data. What we presented already this tables, we can present it in this style here, and we have even some functional buttons here implemented with this, and instructing the browser to have this buttons, and so you can jump to the top, you can open up the source display as a bookmarks. It's not here yet, bookmarks, but modules is this part, and functions is this part, and variables would be another one, and so on. So, that is what we offer, and so you can have it with color or without. Yeah. So, that is already available and it's not a lot of work to document what's the code coverage per app. For sure, it's not a big step from the XML to the PDF. What? What covers reporting standpoint in following industry guidelines for a particular application market in order to generate complete code coverage, do they work on it in sections, and then aggregate all the coverage together? If necessary, they do it, yes. They try for sure to cover all automatically like changing the conditions by script files, pushing virtually the button by script files, and so on. So, it is very often happening that was not a topic that I wanted to present here, but there is the possibility that if you are in development you will use our tool, and you effluent script files, and buttons that do some stuff for you automatically. But, if you are in production or in quality control, then you have a large set of script files, which do the tests in always the same way. They even lock or encrypt the file, so nobody touches them. After five years, still the same script file that they run, and they can compare why is the software version different running than this one? Well, instruction coverage that is what you saw, and what I explained, but then it comes decision coverage, and modified conditions. So, that is more tricky. So, here, we have it in the code. So, there is something conditional and so, that is a MC/DC statement here, and such a information, such a statement is only possible if you know the application. Now, how can we as a tool provider know your application? Not really, but we can agree with the compiler manufacturer, or the debug environment manufacturer, development environment manufacturer that within the build process. So, you have source files, and the build process. You can with the help of our preprocessor for the software not hardware, there's a T32 cast, and this can retrieve the information from the build process and convert it into a generic file type, the extended code analyzers file that we can load. It's not our proprietary format, but this is our software that we provide and so, that is something that we agreed about with compiler manufacturers, and so that provides us the information, so we have trace data for our analyzers. We have the executable file as what was executed and so, because like I said, trace data is only a protocol. We need the executable file to disassemble, to know the addresses, and instructions, and so on. So then, as a third part, now we have the ECA. So, this file extended code analyzes file allows us to know, and to handle the modified conditions. So, you can run this, and you can select in our coverage state window, what kind of information you have. For sure, object code, statement coverage, that's easy that was available by tracing, but nowadays, we can even cover decision coverage, and MC/DC, and you can decide what you want to see, so that is a listing regarding this address, so it sets up on this address, and shows the coverage statement coverage, statement coverage, MC/DC coverage. So, you can also look for modules, or certain functions, or list. Yeah, so that is what we have here available, that's the newest stuff and yeah.
