{"id":58607,"date":"2024-09-19T09:52:34","date_gmt":"2024-09-19T13:52:34","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/simcenter\/?p=58607"},"modified":"2026-03-26T06:37:24","modified_gmt":"2026-03-26T10:37:24","slug":"stop-developing-your-cars-in-excel","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/simcenter\/stop-developing-your-cars-in-excel\/","title":{"rendered":"Stop developing your cars in Excel"},"content":{"rendered":"\n

We all know Microsoft Excel and work with colormaps, spectra, time series, but in the end it\u2019s often about Key Performance Indicators \u2013 the KPI\u2019s. The majority of companies have their own procedures to reduce GBs of test data into a couple of statistics, such as an RMS value from an Octave section, or a peak value from a spectrum. Interestingly, these are often calculated in office type of environments, such as Microsoft Excel. <\/p>\n\n\n\n

Now do not get us wrong, there is nothing bad about such type of workflows. The only challenge that we see, is that over time it may become difficult to store, maintain and find these reports back without a relational database in place, and data management in Simcenter Testlab<\/a> can help<\/p>\n\n\n\n

Minimize the workload – frontload annotation<\/h2>\n\n\n\n

The first step in centralizing your data is with annotation. You can\u2019t store years of data in a single location if you cannot distinguish it from each other. Whether you decide to annotate before, during or after data acquisition, the information always travels with the data.<\/p>\n\n\n\n

In the example below you can see the first improvement of Descriptive Annotation in Simcenter Testlab 2406. You can now decide if the colleagues performing the measurements can only select values from a restricted list or add new values while annotating.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

In an ideal situation, 99% of the information you are going to have to annotate is known before the test. Tire model, component variant or the name of the requesting engineer are of course important information, but it would be a waste of time to ask the Test Engineer or the Operator to fill them in. Instead, prepare the Descriptive Annotation Template upfront and let the engineers or operators focus on what they do best: testing.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

These templates can be enriched with defaults and values lists, such that majority of the information is already available.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

The engineers or operators themselves can now change or add extra defaults directly in the software, which will be then kept for all runs that follow.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

How to get your KPIs, no Excel needed<\/h2>\n\n\n\n

The data is measured and annotated, great job! But how do you boil it down to a couple of single values, which can tell you if your prototype performs as expected? This one is easy, the answer is not Excel, but Simcenter Testlab Process Designer. <\/p>\n\n\n\n

For the sake of the example, we will assume that the three KPIs that we will be comparing are RMS values taken on limited 12th<\/sup> octave bands:<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

Let\u2019s create a process together that will extract those interior noise KPIs from a road noise test. We will start by calculating the peak 1\/12th<\/sup> octaves and extracting the three segments (55 Hz \u2013 163 Hz: Rumble<\/em><\/strong>, 307 Hz \u2013 610 Hz: Growl<\/em><\/strong>, 870 Hz \u2013 2180 Hz: Whine<\/em><\/strong>) by using the Extract segments (block) method.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

Since we need the RMS values from different frequency ranges, we are going to use 3 copies of this method. We will follow with a Metadata editing, to make sure that each segment is annotated with the actual KPI name.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

The final step is simple \u2013 connect the Statistics method and calculate an RMS value on each of the frequency segments. Et voil\u00e0<\/em>, we have KPI\u2019s, no spreadsheets needed.<\/p>\n\n\n

\n
\"Replacing<\/figure><\/div>\n\n\n

Let\u2019s not forget about annotation \u2013 we\u2019ve done all this work to make sure that our data is properly annotated. This information can be now used to immediately distinguish the different measured variants. In the example above we\u2019ve replaced the traditional section names with something much more interesting \u2013 the tire make. Easy visualization of the results next to contextual information if something that Simcenter Testlab offers out of the box, while making such comparisons in a spreadsheet takes quite some skill.<\/p>\n\n\n\n

Publishing, where the magic happens<\/h2>\n\n\n\n

Instrumentation? Done. Annotation? Done. Processing? Done! Time to save the results on a shared network drive and call it a day, right? This is indeed how many R&D companies are working, but there is a catch. Either you keep a very strict naming convention regime and make sure everyone adheres to it, or you risk not being able to find your calculated KPIs saved in an Excel file months from now\u2026 tricky, isn\u2019t it?<\/p>\n\n\n\n