Sensor Signal Plausibility, Scaling & Clamping
Safety-critical throttle control relies on dual independent Accelerator Pedal Position sensors (APP1 and APP2). The signals have opposite slopes or different transfer functions. The ECU must cross-validate both signals and clamp calculated throttle demand between 0% and 100% to prevent unintended acceleration.
Overview & Key Concepts
Signal Management in CAPL Scripting
CAPL (CAN Access Programming Language) is a programming language used for simulating, testing, and analyzing CAN (Controller Area Network) bus communications. Signal management in CAPL refers to how you interact with signals (data points or variables) on the CAN network. These signals are transmitted between ECUs (Electronic Control Units) and are part of CAN messages.
Signal management involves reading, writing, and manipulating the values of these signals. CAPL allows for defining and interacting with signals in several ways, such as:
Reading signals from messages
Writing signals to messages
Signal manipulation during simulation or testing
Setting signal values based on events
Logging signal data for analysis
Key Concepts in Signal Management
Signal Declaration A signal in CAPL is typically declared in the environment file or in the Signal section of a CAPL script. Signals can be part of a CAN message, and they are used to represent specific pieces of data in that message. Example: capl variables
{
// Declare a signal of type int with ID 1
int speed;
int rpm;
}
Signal Access You access signals in CAPL by using the message they belong to. You can use predefined messages (such as CAN_Message) or create custom messages to which you assign signals.
Example of accessing a signal:
capl
message CAN_Message {
signal speed;
signal rpm;
}
// Access the signal speed from CAN_Message
int currentSpeed = CAN_Message.speed;
int currentRPM = CAN_Message.rpm;
Reading and Writing Signals You can read signals from messages and assign values to them. These signals can be either input (read-only) or output (writable). Example of reading a signal: capl on message CAN_Message
{
// Read the value of the speed signal
output("Speed: %d", CAN_Message.speed);
}
Example of writing a signal:
capl
on timer t
{
CAN_Message.speed = 100; // Set the speed signal to 100
output("New speed value: %d", CAN_Message.speed);
}
Signal Value Change Detection You can detect when a signal value changes and take action based on that change. Example of detecting a change: capl variables
{
int previousSpeed;
}
on message CAN_Message
{
if (CAN_Message.speed != previousSpeed)
{
output("Speed changed from %d to %d", previousSpeed, CAN_Message.speed);
previousSpeed = CAN_Message.speed; // Update the previous speed value
}
}
Signal Data Types Signals can have different data types, such as int, float, bool, string, etc. The data type of the signal should match the type used in the CAN message definition. Example with multiple data types: capl message CAN_Message
{
signal speed : int;
signal rpm : int;
signal temperature : float;
}
on message CAN_Message
{
output("Speed: %d, RPM: %d, Temperature: %.2f", CAN_Message.speed, CAN_Message.rpm, CAN_Message.temperature);
}
Signal Scaling Signals in CAPL may require scaling (multiplying or dividing by a factor) to convert the raw data values into more useful units, such as converting a speed signal from raw to km/h. Example of signal scaling: capl message CAN_Message
{
signal rawSpeed : int;
}
on message CAN_Message
{
// Assuming the rawSpeed value needs to be divided by 10 to convert to km/h
int scaledSpeed = CAN_Message.rawSpeed / 10;
output("Scaled Speed: %d km/h", scaledSpeed);
}
Signal Event Handling Signals can trigger events or actions when their values change or when certain conditions are met. Example of triggering an event on a signal change: capl on message CAN_Message
{
if (CAN_Message.speed > 120)
{
output("Warning: Speed exceeds limit!");
}
}
Advanced Signal Operations Signals in CAPL can also be manipulated by performing bitwise operations, conditional checks, or other advanced operations, depending on the scenario. Example of bitwise operation: capl message CAN_Message
{
signal flags : int; // 32-bit flags signal
}
on message CAN_Message
{
if (CAN_Message.flags & 0x01) // Check if the least significant bit is set
{
output("Flag 0 is set");
}
}
Example Scenario: Signal Management in a CAN Network
Let's say you are working on a simulation to test the CAN network of a vehicle, which involves messages like VehicleStatus and EngineControl.
Step 1: Signal Definition
In your environment file, you might define messages and signals like this:
message VehicleStatus
{
signal speed : int; // Speed of the vehicle (in km/h)
signal fuelLevel : float; // Fuel level percentage
signal engineStatus : bool; // Engine status (running or off)
}
Step 2: Reading Signals
In your CAPL script, you can read signals when the message is received:
on message VehicleStatus
{
output("Speed: %d km/h", VehicleStatus.speed);
output("Fuel Level: %.2f%%", VehicleStatus.fuelLevel);
output("Engine Running: %s", VehicleStatus.engineStatus ? "Yes" : "No");
}
Step 3: Writing Signals
You can modify or simulate signal values. For instance, you could write to a message based on some condition:
on timer t
{
// Simulate speed change
VehicleStatus.speed = 80; // Set speed to 80 km/h
output("Speed set to %d km/h", VehicleStatus.speed);
// Simulate fuel level drop
VehicleStatus.fuelLevel = 50.0; // Set fuel level to 50%
output("Fuel Level set to %.2f%%", VehicleStatus.fuelLevel);
}
Step 4: Signal Scaling
You might need to scale the signals for accurate simulation, such as adjusting sensor data:
on message VehicleStatus
{
// Convert raw speed signal (e.g., 1000 = 100 km/h)
int scaledSpeed = VehicleStatus.speed / 10;
output("Scaled Speed: %d km/h", scaledSpeed);
}
Conclusion
Signal management in CAPL scripting involves interacting with and manipulating signals within CAN messages. You can define, read, write, and scale signals to simulate realistic CAN communication in embedded systems or testing environments. By mastering signal management, you can automate tests, simulate complex scenarios, and handle real-time data more effectively.
- Never perform float equality checks (`s1 == s2`); always check whether the difference is within an acceptable epsilon window (`abs(s1 - s2) < EPSILON`).
- Ensure that signals with negative offsets (such as outdoor temperature -40 °C) are represented with signed types in the DBC.
Select your answer for each question below to receive immediate correctness evaluation and in-depth technical rationale.
Write a CAPL function that reads two pedal sensor percentages (`float sensor1, float sensor2`). If the difference between them exceeds 8.0%, trigger a safety fault and clamp output throttle to 0.0%. Otherwise, return the average of the two sensors.
Verified CAPL implementation:
float ProcessPedalSignals(float s1, float s2)
{
float diff = s1 - s2;
if (diff < 0) diff = -diff; // Absolute difference
if (diff > 8.0)
{
writeLineEx(0, 3, "SAFETY CRITICAL: Pedal sensor discrepancy (Diff: %.1f%%). Forcing 0%% throttle!", diff);
$ThrottleSafetyFault = 1;
return 0.0; // Fail-safe default
}
$ThrottleSafetyFault = 0;
return (s1 + s2) / 2.0;
}