SSAT will inspect the following for vehicle-mounted software as per your needs:
Global variable initialization
API usage errors
Recursive Functions
Race conditions
In general, static analysis of software is a technique for analyzing source code without running the
target program.
Global Variable Initialization Check
Checks that all global variables contained in the target module are properly initialized. Proper variable
initialization means that it is initialized with a declaration. That is, it checks whether the variable is
initially specified in the declared syntax. If you are going through an initialization process elsewhere other
than the declaration location, the declaration location will display as unsatisfactory as not initialized.
The check looks for the global variable and reports its location, and if there is no syntax for initializing it,
it treats it as an error. This is meant as a device to prevent variable initialization from falling out.
API Usage Error Check
hecks the source code contained in the target module for violations of API usage rules.
It currently supports checks for five types of API usage errors.
API Usage Error Type
Type 1 [A-]: Error that the first function of the API was called in that task, but not the second function
Type 2 [-B]: Error that the second function is called without the api's first function being called in that
task
Type 3 [AA]: Error that the first function of the API in that task is called in a row without a second
function call
Type 4 [BB]: Error in which only the second function is called in a row without the api's first function
call in that task
Type 5 [ABC]: Error that the second (third) function is called when the first (second) function of a
particular API pattern is not called in that task.
If it is performed in a multi-task environment, the error being detected may not be the actual error. If
two tasks call functions in one API pattern one by one in the correct order, they are not actually
errors, but static analysis cannot guarantee the execution order of each task, so it detects them as
errors.
When using the AUTRON AUTOSAR platform, task-specific function information refers to sub-functions
called from the \Generated\Bsw_Output\src\Rte.c in-file task function (e.g. OsTask_ASW_FG1_10ms)
generated by the development tool Mobilgene/ODIN environment.
Recursive Function Check
Checks for calls that are called directly or recursively as indirect calls through function pointers, including
when a continuous call cycles through a function call.
The recursive function is detected by Strongly Connected Components (SCC). Functions contained in SCC can be
reached by other functions in any function, so all included functions are recursive.
The recursive function check performs an analysis taking into account indirect calls using function
pointers.
Indirect functions are displayed as dotted lines on the function call graph.
Race Condition Check
A race condition for a global variable is a state in which a task writes to a global variable and can have a
different effect on the value of the global variable, depending on the time or order of the operation. In this
case, there is a risk of different results than expected, depending on the timing or order.
In a multi-task environment, global variables (including static variables) can be accessed by multiple tasks at
the same time. As a way to prevent this approach, the use of sequential APIs allows you to configure critical
sections and write to global variables only inside that section.
Race condition checks take critical sections into account in a multi-task environment to determine whether race
conditions can occur in global variables. In other words, if a large number of processes write to a global
variable where critical sections are not configured, a race condition is determined to exist. This check checks
for the existence of race conditions for all global variables (including static variables) and provides
information about which processes have write access to which variables if they exist.
When using the AUTRON AUTOSAR platform, task-specific function information refers to sub-functions
called from the \Generated\Bsw_Output\src\Rte.c in-file task function (e.g. OsTask_ASW_FG1_10ms)
generated by the development tool Mobilgene/ODIN environment.
Add Module button: You can add a new module to use.
Analysis names are limited to a maximum of 32 characters, and only a combination of English letters and
numbers is available. Spaces, Unicode, and special characters are not available.
SSAT targets one module. If you want to analyze multiple modules, you need to perform as many analyses
as you want.
Select analysis
By default, all four checks are selected.
The Settings tab of the checked-off check is disabled.
Global Variable Initialization Check
Exclude EXTERN variables: Select whether to exclude external variables (EXTERN variables) that are difficult
to determine whether to initialize with the information in that module alone.
"sm2nd_cfg.c" scan: Include the "sm2nd_cfg.c" file in the scan. When you enter a file path, you find the
file in the path you entered, or in the directory included in the module if you do not enter a file path, or
if the file you entered does not exist. Perform a scan only if the file is found.
"nm_cfg.h" scan: Include the "nm_cfg.h" file in the scan. When you enter a file path, you find the file in
the path you entered, or in the directory included in the module if you do not enter a file path, or if the
file you entered does not exist. Perform a scan only if the file is found.
Patterns to check: Shows the API patterns to be examined. The platform depends on the type of API pattern
you are checking and the type of error. You can see this on the selected platform in the table below.
A platform must be selected to create an SSAT analysis.
Recursive Function Check
There are no recursive checkes available.
Race Condition Check
Task Group
Task Gropu List
Group ID: The task group ID. You can automatically grant or enter tasks when you add them, and the group ID
must be unique.
Size: The number of tasks selected.
Start function: The function name.
Reachable: The number of functions that can be reached by a function call from this function. include
yourself.
Manage task group lists
Add task groups: Add new task groups to the list.
Change task group: Changes the information in the selected task group.
Delete Task Group: Deletes the selected task group.
If you select Add or change a task group, the Edit Task Group screen below shows.
Edit Task Group screen
Left list: Shows the tasks available for selection in the module.
Right list: Shows the tasks selected in the module.
Group ID: The task group ID. You can automatically grant or enter tasks when you add them, and the group ID
must be unique.
Start function: The function name.
Root: Displays as root if it is not called from another function.
Reachable: The number of functions that can be reached by a function call from this function. include
yourself.
At least one file must be selected.
You can select a group ID that already exists and add it to an existing group.
Tasks can be grouped together, in which case tasks in the same group are considered sequential and do
not check the race conditions between tasks within the same group.
Critical section
Begin API: The function from which the critical section begins.
Eng API: A function that terminates the critical section.
Add critical sections: Add entered start AND end API pairs as critical sections.
Delete Critical Section: Deletes the selected critical section from the list.
The Critical Section tab specifyes a Critical Section that is known to be accessible to only one task at
a time.
All execution paths that start from the start API and reach the exit API are specified as critical
sections.
Three items are added by default and can be deleted or added by the user.
The code area from the start API to the exit API in each critical section added does not check for race
conditions.
Declaration: Declaration location of global variable, but not '-' if source code is missing or location
cannot be found
Remark: The user gets a commented description in the code. However, if you want to be on the same line
@HKSAT, you should start with a name-init and add a description.
In the results table, double-click an item to show the location of its variables in code and graph
views.
The following initialization variables related to CAN display the initialization value if the file is
included in the analysis (if it exists in a directory that contains the source code):
sm2nd_cfg.c: cuw_SM_KATAfterPwrOnWU (Set in Configuration Tool)
nm_cfg.h: NM_COUNT_RING_TYP, NM_COUNT_RING_MAX, NM_COUNT_LIMPHOME, NM_COUNT_WAIT_BUSSLEEP
(Set in GENY)
API usage error checking results
API pattern: Shows the API pattern in which usage errors were found. The pattern is marked by ->
Root: The name of the function from which the task begins. If the functions have the same name, it means
that they were performed on the same task.
Start and End locations: Different types of errors are displayed. (See description below)
Type: Displays the type of API error.
Description: Displays a description of the error type.
Type 1 [A-]: Where the start position was called by the first function, and where the end position
ended the task.
Type 2 [-B]: Where the start position started the task started, and where the end position was
called by the second function.
Type 3 [AA]: Where the first function was called, where the first function was called, and where the
first function was called once more.
Type 4 [BB]: The start position becomes where the second function is called, and the exit position
is where the second function is called once more.
Type 5 [ABC]: Where the start location started the task started, where the end position was called,
and where the second or third function was called.
Remark: The user gets a commented description in the code. However, if you want to use the same line @HKSAT,
you should start with the same-MATT and add a description.
You can double-click an item in the results table to see the location of the recursive function in code
view and the structure of the function in graph view. Also, if you select a list that corresponds to the
included functions column, you can see the call graph between all functions associated with that
recursive.
Recursive Function Check Result
Function: Name of the recursive call function
Group ID: The SCC ID that contains the function
Size: The number of functions included in that SCC
Remark: The user gets a commented description in the code. However, if you want to @HKSAT code, you should
start with Recu and add a description.
You can double-click an item in the results table to see the location of the recursive function in code
view and the structure of the function in graph view. Also, if you select a list that corresponds to the
included functions column, you can see the call graph between all functions associated with that
recursive.
Race Condition Check Result
Variable: Displays the name of the variable that causes the race condition.
Type: Displays the data type of that variable.
Task Group Count: Displays the number of task groups that write to and access that variable.
Task groups: Lists the names of task groups that access the variable by commas.
Remark: The user gets a commented description in the code. However, if you want to @HKSAT code, you should
start with A-RACE and add a description.
You can double-click a variable in the results table to show the location of the variable in code view.
Add all tasks when created: Add the root function, which is a function that is not called from any of the
functions when the analysis is created, as a task in the race condition check.
Load default critical section pattern: Pre-add known critical sections when you create an analysis.
Code View Highlight Colors
Global variable init error is the color for uninitialized global variables in code blocks in the code view.
API pattern errors is the color for API pattern errors in the code view.
Recursive functions is the color for recursive functions in the code view.
Race conditions is the color for race condition variables in the code view.