Do you know what VSS is? If you work in automotive, it might refer to the vehicle speed signal on the internal bus system. Okay… but is is km/h or mph?
Complex, software-defined products can have tens of thousands of such symbol names. Few people know them all, let alone details like ranges, units or other properties.
Not fully understanding a signal name can lead to misunderstandings, which can easily lead to delays and expensive rework. In the worst case scenario, this could even lead to accidents and expensive recalls.
Imagine seeing detail information from your signal names as tool tips in your design document (e.g. in Polarion), the details taken from your SysML modeling tool (e.g. Enterprise Architect).
Semiant can augment your design document by injecting tooltips with this information, using glossary management. This works in many tools, like Confluence, DOORS Next or Codebeamer. It’s up to you whether the source is a modeling tool like Rhapsody or an Excel spreadsheet. Here is an example how this would look like:
Forbid problematic acronyms in the first place
VSS can mean “Vehicle Speed Signal”, but also “Vehicle Speed Sensor”. Even worse, both could be valid in the same context (automotive development). For this reason, you can mark these signals as “forbidden” and offer alternatives. For instance, “VS_Sig” for the signal and VS_Sensor for the sensor.
Align language across teams
Of course, your infotainment team might develop a Visual Surround System that they also call VSS. Semiant allows different teams to have their own glossaries. Multiple glossaries can be active at the same time, giving teams visibility of each other’s terminology.
As Semiant makes it easy for teams to maintain and evolve their glossaries, this will continuously align an organization’s language, even across teams.
Conclusion: Understanding signal names helps you master complexity
Semiant helps you mastering complexity by aligning the language of all teams in your organization, across the tools that you use every day.