1
What is the difference between a Simulink model and a MATLAB script?
Answer
A MATLAB script is text-based sequential code for numerical computation and analysis. A Simulink model is a graphical block-diagram environment for modeling dynamic systems using signal-flow connections. Simulink natively supports continuous-time and discrete-time simulation, automatic code generation, and visual debugging. In automotive, Simulink models are the primary design artifact for control algorithms that get auto-coded to C for ECUs.
2
What are the main solver types in Simulink and when do you use each?
Answer
Fixed-step solvers (ode1, ode3, ode4, ode5, ode8) advance time by a constant step - required for code generation and real-time execution. Variable-step solvers (ode45, ode23, ode15s) automatically adjust step size for accuracy - used during algorithm development and plant simulation. ode45 (Dormand-Prince) is the default for non-stiff systems; ode15s handles stiff systems. Automotive ECU code always uses fixed-step.
3
What is the difference between sample time and simulation step size?
Answer
Step size is the solver's time increment for advancing the simulation. Sample time is a block-level property defining how often a block executes. A model can have multiple sample times (multi-rate): a sensor block at 10ms and a control loop at 1ms. The solver step size must be an integer divisor of all sample times. Rate Transition blocks handle data passing between different rates.
4
Explain the difference between virtual and non-virtual subsystems.
Answer
Virtual subsystems are purely organizational - they group blocks visually but have no computational effect; during simulation and code generation, they are flattened. Non-virtual subsystems (Atomic, Enabled, Triggered, Function-Call) have execution semantics - they can be conditionally executed, have their own sample time, and generate separate functions in code. Atomic subsystems are key for modular code generation.
5
What is an Enabled Subsystem?
Answer
An Enabled Subsystem executes only when its enable port receives a positive signal. When disabled, outputs can be held at their last value or reset to initial conditions (configurable). It generates an enable/disable function pair in code. Use cases: mode-dependent algorithms (e.g., cruise control active only when enabled), conditional feature execution, and power-saving logic that disables unused computations.
6
What is a Triggered Subsystem?
Answer
A Triggered Subsystem executes once per trigger event - on rising edge, falling edge, or either edge of the trigger signal. Unlike Enabled Subsystems (which run every step while active), Triggered Subsystems run exactly once per event. Common uses: interrupt-driven processing, event-based state transitions, and capturing data at specific moments. They map to ISR-like functions in generated code.
7
What is a Function-Call Subsystem?
Answer
A Function-Call Subsystem executes when invoked by a function-call initiator (e.g., a Stateflow chart, Function-Call Generator, or S-Function). It provides explicit control over execution order and timing, unlike sample-time-driven blocks. In code generation, it produces a callable function. Essential for: AUTOSAR runnables, OS task mapping, and Stateflow-orchestrated execution sequences.
8
What is Model Referencing and how does it differ from a Library?
Answer
Model Referencing (Model block) includes another model as a component with independent compilation - changes recompile only the changed model. Libraries share block definitions across models but are copy-on-use and compiled with the parent. Model References support: incremental builds, independent testing, protection (P-code), and different solver/sample-time settings. They map well to AUTOSAR SWC boundaries.
9
What are Bus Objects and when should you use them?
Answer
Bus Objects define structured signal types - named collections of signals with specified data types, dimensions, and hierarchy (like C structs). Use Simulink.Bus objects for: grouping related signals (sensor data, control outputs), enforcing signal interfaces between components, mapping to AUTOSAR port interfaces, and clean code generation with struct types. Virtual buses group signals without type checking; non-virtual buses enforce the Bus Object definition.
10
What is the Rate Transition block and why is it important?
Answer
Rate Transition blocks safely transfer data between blocks running at different sample rates, preventing data corruption from concurrent read/write. They implement double-buffering or zero-order hold depending on configuration. Options: ensure data integrity (protect against torn reads), ensure determinism (consistent output timing). For AUTOSAR, Rate Transition maps to the RTE's inter-runnable variable mechanism.
11
What are Variant Subsystems and how are they used in automotive?
Answer
Variant Subsystems contain multiple implementations where only one is active, selected by a Variant Control variable. Selection can happen at: model loading, code compilation (#if/#else), or startup (if-else). Automotive use: same model supports left-hand/right-hand drive, gasoline/diesel variants, or regional feature sets. In generated code, compile-time variants produce smaller binaries with only the active variant included.
12
Explain Data Store Memory vs Signal Lines.
Answer
Signal lines represent directed data flow between blocks - explicit, traceable connections. Data Store Memory provides shared global-like variables accessible by any block in the model via Data Store Read/Write - implicit data flow. Signal lines are preferred for clarity and traceability. Data Store Memory is used for: mode flags accessed across subsystems, calibration parameters, and legacy model patterns. MAAB guidelines restrict its use.
13
What is the Simulink Model Advisor?
Answer
Model Advisor is a built-in tool that checks models against configurable rule sets for: modeling guidelines compliance (MAAB, MISRA-C mapping), code generation readiness, simulation performance, and safety/certification standards (DO-178C, ISO 26262). It reports violations with descriptions and automated fixes. Custom checks can be added. Running Model Advisor is a required step in most automotive MBD processes.
14
What are S-Functions and when are they needed?
Answer
S-Functions (System Functions) are user-written blocks in C, C++, MATLAB, or Fortran that extend Simulink's block library. Use cases: wrapping legacy C code, modeling hardware-specific behavior, implementing algorithms not available as built-in blocks, and interfacing with external libraries. C MEX S-Functions offer the best performance and code generation support. TLC (Target Language Compiler) files customize generated code.
15
What is Stateflow and how does it relate to Simulink?
Answer
Stateflow is a state machine and flow chart environment integrated within Simulink. It models event-driven, reactive, and modal logic using hierarchical state machines with states, transitions, events, and actions. Stateflow charts execute as blocks within Simulink models, receiving inputs and producing outputs. In automotive: mode managers, diagnostic state machines, gear shift logic, and drive mode selection.
16
Explain the difference between states and junctions in Stateflow.
Answer
States represent persistent modes of operation - the system stays in a state until a transition condition is met. States have entry, during, and exit actions. Junctions are transient decision points - flow passes through them without stopping. Connective junctions implement if-else logic and for-loops in flow charts. History junctions remember which substate was last active. States persist; junctions are instantaneous.
17
What are entry, during, and exit actions in Stateflow?
Answer
Entry actions execute once when a state is entered - used for initialization (set outputs, start timers). During actions execute every time step while the state is active - used for continuous behavior (update outputs, check conditions). Exit actions execute once when leaving a state - used for cleanup (reset outputs, stop timers). Syntax: entry: output = 1; during: count = count + 1; exit: output = 0;
18
What is the difference between inner and outer transitions?
Answer
Outer transitions go from one state to another - they trigger exit actions of the source and entry actions of the target. Inner transitions stay within the same state but can trigger re-entry of substates. Self-transitions (from a state back to itself) execute exit then entry actions. Inner transitions execute during actions without leaving. This distinction is critical for proper state machine behavior.
19
How does hierarchy work in Stateflow?
Answer
States can contain substates creating a hierarchy. Exclusive (OR) decomposition means only one substate is active at a time - represents modes. Parallel (AND) decomposition means all substates are active simultaneously - represents concurrent processes. Hierarchy enables: grouping related states, default transitions for initial substates, history junctions to remember last active substate, and transition shortcuts using super-state boundaries.
20
What are Stateflow events and how are they used?
Answer
Events trigger transitions and actions in Stateflow. Input events come from Simulink (edge-detected signals) or function calls. Local events are broadcast within the chart. Temporal events use temporal logic: after(5, sec), every(10, tick). Events enable: edge-triggered state transitions, periodic actions, timeout handling, and inter-chart communication. In automotive: CAN message received, button press, timer expiry.
21
What is temporal logic in Stateflow?
Answer
Temporal logic uses time-based conditions: after(N, event) - true after N occurrences of event. before(N, event) - true before N occurrences. every(N, event) - true every Nth occurrence. at(N, event) - true at exactly the Nth occurrence. With tick (chart execution): after(100, tick) at 10ms = 1 second delay. With sec/msec: after(5, sec) = 5-second timeout. Essential for: debouncing, timeouts, periodic checks.
22
How do you handle default transitions in Stateflow?
Answer
A default transition points to the initial substate when a parent state is entered. Every exclusive (OR) state with substates must have a default transition - otherwise Stateflow doesn't know which substate to activate first. Default transitions can have conditions and actions. For history junctions, the default transition is taken only on the first entry; subsequent entries restore the last active substate.
23
What are Stateflow truth tables?
Answer
Truth tables define combinational logic using a table of conditions and actions - each column specifies a unique combination of true/false conditions and the resulting actions. They are alternatives to complex flow charts or nested if-else logic. Stateflow auto-generates efficient code from truth tables. Use cases: complex decision logic, diagnostic enable conditions, and safety interlock logic.
24
What is the difference between Mealy and Moore machines in Stateflow?
Answer
Moore machines: outputs depend only on the current state (defined in state actions). Mealy machines: outputs depend on current state AND inputs (defined on transitions). Stateflow supports both. MAAB guidelines prefer Moore-style charts for automotive because outputs are more predictable and easier to test. Moore: output = f(state). Mealy: output = f(state, input). In practice, most automotive charts mix both.
25
How do you avoid common Stateflow modeling errors?
Answer
Common errors and prevention: 1) Missing default transitions - always add one per exclusive state. 2) Transition conflicts - ensure mutually exclusive conditions or define explicit priority. 3) Infinite loops in flow charts - add safeguard max-iteration limits. 4) Accessing chart-level data from parallel states without protection - use Data Store for shared state. 5) Ambiguous event broadcasting - use directed events.
26
How does Stateflow generate C code?
Answer
Stateflow generates C code as part of Embedded Coder: each chart becomes a step function called at the chart's sample rate. States map to enumerated state variables. Transitions map to if-else chains ordered by priority. Entry/during/exit actions inline at appropriate points. The generated code maintains state variables in a struct. Configuration options control: state variable type, function naming, and inlining of small charts.
27
What is Embedded Coder and how does it differ from Simulink Coder?
Answer
Simulink Coder generates generic C/C++ code for rapid prototyping. Embedded Coder adds production-quality optimizations: MISRA-C compliance, configurable storage classes, function interfaces, custom data types, code tracing to model, and target-specific optimizations. Embedded Coder is required for automotive ECU code generation. It produces smaller, faster code with control over every aspect of the generated output.
28
What are Storage Classes in Embedded Coder?
Answer
Storage Classes define how model signals and parameters appear in generated code: Auto (compiler decides, often local variable), ExportedGlobal (global variable in generated file), ImportedExtern (declared extern, defined elsewhere), Const (const-qualified), Volatile, Bitfield, and custom classes. Proper storage class assignment is critical for: calibration tool access (XCP), AUTOSAR RTE mapping, and memory section placement.
29
How do you generate AUTOSAR-compliant code from Simulink?
Answer
Steps: 1) Use AUTOSAR Blockset to configure the model as an AUTOSAR SWC. 2) Define ports mapping to AUTOSAR R-Ports/P-Ports. 3) Configure runnables from Function-Call Subsystems. 4) Set AUTOSAR data types and interfaces. 5) Generate code with System Target File: autosar.tlc. Embedded Coder produces: SWC C code, ARXML descriptions (ports, interfaces, runnables), and RTE-compatible function signatures.
30
What is a TLC file in code generation?
Answer
TLC (Target Language Compiler) files are template scripts that control how Simulink blocks generate C code. Each block has a corresponding .tlc file defining its code output. System TLC files (e.g., ert.tlc, autosar.tlc) control the overall code structure. Custom TLC files can override default code generation for S-Functions or create target-specific optimizations. TLC uses a markup language with %% directives.
31
How do you ensure MISRA-C compliance in generated code?
Answer
1) Enable 'MISRA C:2012 guidelines' in Code Generation > Code Style. 2) Use Embedded Coder's MISRA-compliant code patterns (explicit casts, braces, no recursion). 3) Run Model Advisor MISRA checks before generation. 4) Configure data types to avoid implicit conversions. 5) Post-process with static analysis tools (Polyspace, LDRA). 6) Use Code Mapping to control naming and types. Embedded Coder R2020b+ achieves near-100% MISRA compliance.
32
What is SIL (Software-in-the-Loop) testing in Simulink?
Answer
SIL testing executes generated C code within the Simulink environment. The model block is replaced with compiled generated code running on the host PC. Test inputs come from Simulink test harnesses, and outputs are compared with the original model (back-to-back testing). SIL verifies: code generation correctness, numerical equivalence (within tolerances), and proper function interfaces. It's faster than PIL and doesn't need target hardware.
33
What is PIL (Processor-in-the-Loop) testing?
Answer
PIL testing executes generated code on the actual target microcontroller (or instruction-set simulator) while Simulink provides test stimuli and collects results via a serial/JTAG connection. PIL verifies: target compiler effects, fixed-point behavior on actual hardware, execution time measurement, and stack usage. It catches issues that SIL misses: compiler optimizations, byte alignment, and hardware-specific numerical behavior.
34
What is Code Traceability in Embedded Coder?
Answer
Code traceability links generated C code lines bidirectionally to Simulink model elements. Forward tracing: model block → code lines. Backward tracing: code line → model block. Implemented via HTML reports or IDE integration. Required by ISO 26262 Part 6 and ASPICE SWE.3 for demonstrating that all requirements are implemented and all code is traceable to design. Embedded Coder generates traceability reports automatically.
35
How do you optimize generated code size and speed?
Answer
Size: enable expression folding, inline parameters, remove unnecessary type casts, use smaller data types, eliminate dead code paths, use lookup table optimization. Speed: use inlined functions, optimize loop rolling, use hardware-specific intrinsics, enable SIMD where available. Configuration: Code Generation > Optimization settings. Use Code Metrics report to identify largest functions. Profile PIL execution for hotspots.
36
What is the Legacy Code Tool?
Answer
Legacy Code Tool integrates existing hand-written C/C++ code into Simulink models. It generates S-Function wrappers that call the external code during simulation and inline the code during generation. Steps: define function signature, specify source/header files, generate the S-Function block. Use cases: reusing validated library functions, integrating supplier code, and wrapping hardware driver APIs.
37
What are code replacement libraries (CRL)?
Answer
CRLs replace standard generated code patterns with optimized implementations for specific targets. Example: replace generic multiply-accumulate with ARM DSP intrinsic __SMLAD. MathWorks provides CRLs for ARM Cortex-M, Intel, TI DSP. Custom CRLs can be created for proprietary hardware. They improve performance without changing the model. Configure via: Code Generation > Interface > Code Replacement Library.
38
How does Embedded Coder handle multi-rate models?
Answer
For multi-rate models, Embedded Coder generates either: Single-tasking - one step function executes all rates sequentially (simpler, higher latency). Multi-tasking - separate functions per rate with rate monotonic scheduling (base rate in fastest task, sub-rates in slower tasks). Rate Transition blocks generate protection code (double-buffering). The generated code includes rate scheduler logic compatible with AUTOSAR OS or RTOS.
39
What is an ERT (Embedded Real-Time) system target file?
Answer
ert.tlc is the default Embedded Coder target that generates production-quality standalone C code. It produces: model_step() function called at the base rate, model_initialize() for startup, and model_terminate() for cleanup. The code is RTOS-independent and includes a static scheduler. AUTOSAR target (autosar.tlc) extends ERT with AUTOSAR-specific function signatures and ARXML generation.
40
What is the Code Generation Report?
Answer
The HTML report generated by Embedded Coder contains: generated file list, code metrics (lines, RAM, ROM estimates), traceability links (model↔code), code interface documentation (function prototypes, global variables), MISRA compliance summary, and static code analysis results. It serves as a development artifact for ASPICE SWE.3 evidence and ISO 26262 traceability requirements.
41
Why is fixed-point arithmetic used instead of floating-point in automotive ECUs?
Answer
Many automotive MCUs (especially low-cost ones) lack an FPU, making floating-point operations 10-100x slower via software emulation. Fixed-point provides: deterministic execution time, smaller code size, bit-exact reproducibility, MISRA-C compliance (avoiding float pitfalls), and sufficient precision for most control algorithms. Even with FPU-equipped MCUs, fixed-point is used for ASIL-D functions due to its deterministic and verifiable nature.
42
What is fixed-point representation in Simulink?
Answer
Fixed-point uses scaled integers: RealWorldValue = StoredInteger × 2^(-FractionLength) + Bias. In Simulink, specified as fixdt(Signed, WordLength, FractionLength). Example: fixdt(1,16,8) = signed 16-bit with 8 fractional bits, range [-128, 127.996], resolution 0.00390625. Simulink's Fixed-Point Designer automates scaling, overflow handling, and type propagation throughout the model.
43
What is the difference between Fixed-Point Best Precision and Binary Point scaling?
Answer
Binary Point scaling: RealValue = Integer × 2^(-FractionLength). Simple but limited to powers-of-2 resolution. Best Precision: Simulink automatically calculates the optimal fraction length for a given word length and expected data range, maximizing precision. Slope-Bias scaling: RealValue = Integer × Slope + Bias, allows arbitrary resolution but generates more complex code. Binary Point is preferred for code efficiency.
44
How do you handle overflow in fixed-point design?
Answer
Two modes: Saturate - clamps the result to the maximum/minimum representable value (safe but introduces nonlinearity). Wrap - wraps around like unsigned integer overflow (fast but can cause sign inversion). Simulink configures this per block. For safety-critical automotive code, saturation is mandatory (MISRA and ISO 26262). Overflow detection can be added via Simulink's diagnostic settings to flag issues during simulation.
45
What is the Fixed-Point Tool in Simulink?
Answer
The Fixed-Point Tool automates conversion from floating-point to fixed-point models. Workflow: 1) Run floating-point simulation to collect signal ranges. 2) Tool proposes data types (word lengths, fraction lengths) based on ranges and precision requirements. 3) Review and accept proposals. 4) Validate by comparing fixed-point results against floating-point baseline. It dramatically reduces manual fixed-point conversion effort.
46
What is the difference between Q-format notation and Simulink notation?
Answer
Q-format (used in DSP): Qm.n means m integer bits and n fractional bits. Q15 = Q0.15 = signed 16-bit with 15 fractional bits. Simulink notation: fixdt(Signed, WordLength, FractionLength). Q15 = fixdt(1,16,15). The total word length in Q-format is m+n+1 (for signed) or m+n (unsigned). Simulink's notation is more explicit and handles the sign bit automatically.
47
How does Simulink handle data type propagation?
Answer
Simulink propagates data types through the model: blocks inherit types from connected inputs, with rules for mixed-type operations. The Output data type parameter can be: Inherit (auto-propagate), fixdt() (explicit), or Use Expression. For arithmetic: addition aligns to the most precise input; multiplication produces a full-precision intermediate result then casts to output type. Data Type Override allows switching entire model between double/single/fixed for testing.
48
What is a lookup table and how is it implemented in fixed-point?
Answer
Lookup tables approximate complex functions (sin, log, calibration maps) with stored input-output pairs and interpolation. In Simulink: 1-D Lookup Table, 2-D Lookup Table, n-D Lookup Table blocks. For fixed-point: table data and breakpoints use fixed-point types; interpolation uses fixed-point arithmetic. Prelookup blocks separate index search from interpolation for efficiency. Code generation produces array lookups with linear interpolation.
49
How do you verify fixed-point model accuracy?
Answer
1) Back-to-back simulation: run floating-point and fixed-point models with same inputs, compare outputs quantitatively (max error, RMS error). 2) Data Type Override: switch model between float and fixed to compare. 3) Simulink Design Verifier: prove properties (e.g., output always within ±5% of float). 4) Range analysis: verify no overflow/underflow. 5) Bit-true PIL testing: confirm target hardware matches simulation.
50
What is Data Type Override and how is it used?
Answer
Data Type Override globally changes all data types in a model or subsystem to Double, Single, or ScaledDouble - overriding fixed-point specifications. Use cases: debug numerical issues by running in full-precision float, compare float vs fixed outputs (back-to-back), and develop algorithms in float before fixed-point conversion. ScaledDouble simulates fixed-point quantization effects while using double arithmetic for intermediate results.
51
What is Simulink Test and how is it used?
Answer
Simulink Test provides a test management framework: Test Manager organizes test cases, test suites, and test results. Test Harness creates isolated test environments for subsystems. Verify blocks define pass/fail criteria using temporal logic. Signal Builder/From Workspace provide test stimuli. Results include pass/fail, coverage metrics, and comparison plots. Essential for ISO 26262 requirements-based testing and ASPICE SWE.4.
52
What is Simulink Design Verifier?
Answer
Design Verifier uses formal methods (constraint solving, model checking) to mathematically prove properties of Simulink models without exhaustive simulation. Capabilities: property proving (prove assertions hold for ALL inputs), test generation (automatically create test cases for coverage), dead logic detection (find unreachable states), and design error detection (detect integer overflow, division by zero). Satisfies ISO 26262 formal verification requirements.
53
What coverage metrics does Simulink provide?
Answer
Simulink Coverage supports: Decision Coverage (every if/switch outcome), Condition Coverage (every Boolean sub-condition), MC/DC (each condition independently affects decision), Signal Range Coverage, Lookup Table Coverage, Stateflow coverage (state, transition, condition), and Simulink block execution coverage. MC/DC is required by ISO 26262 for ASIL D software. Coverage reports map to model elements.
54
What is back-to-back testing?
Answer
Back-to-back testing runs the same test inputs through two implementations and compares outputs: MIL vs SIL (model vs generated code on host), SIL vs PIL (host code vs target code), or Simulation vs Specification. Differences indicate: code generation errors, numerical precision issues, or compiler-specific behavior. ISO 26262 Part 6 recommends back-to-back testing for all ASIL levels. Tolerances must be justified.
55
How is requirements traceability achieved in Simulink?
Answer
Requirements Toolbox links external requirements (from DOORS, ReqIF, Excel) to Simulink model elements, test cases, and generated code. Bidirectional links enable: forward tracing (requirement → design → code → test), backward tracing (test → code → design → requirement), and impact analysis. Traceability matrix reports show coverage and gaps. Required by ASPICE SWE.1-SWE.6 and ISO 26262.
56
What is the Polyspace integration with Simulink?
Answer
Polyspace can be run directly on Embedded Coder generated code. Bug Finder checks for MISRA compliance and common defects. Code Prover mathematically proves absence of runtime errors. Integration workflow: generate code → run Polyspace → review results with traceability back to model blocks. Polyspace findings on generated code are mapped to the Simulink model element for easy root-cause analysis.
57
What is Test Harness in Simulink?
Answer
A Test Harness is an isolated test environment that wraps a subsystem or model reference with inputs, outputs, and test infrastructure - without modifying the original model. Each component can have multiple harnesses for different test scenarios. Harnesses contain: Signal Builder/From Workspace for inputs, Scope/To Workspace for outputs, and Verify/Assert blocks for criteria. They support independent testing by different team members.
58
How do you test Stateflow charts?
Answer
Approaches: 1) Simulink Test Manager with temporal assessments - verify state sequence and timing. 2) Design Verifier for formal property proving - prove states are reachable and transitions are correct. 3) Stateflow coverage analysis - ensure all states entered, transitions taken, conditions exercised. 4) Test vectors from Stateflow truth tables. 5) Graphical animation - visually step through chart execution.
59
What is Model-Based Design (MBD) and how does it fit the V-model?
Answer
MBD uses executable models as the primary development artifact. In the V-model: Requirements → Simulink model (design), simulation testing (MIL), auto-code generation, SIL/PIL verification, HIL validation. Benefits: executable specification, early error detection, automatic code generation, automatic test generation, and complete traceability. ISO 26262 and ASPICE support MBD as a valid development method with specific guidance.
60
What are MAAB (MathWorks Automotive Advisory Board) guidelines?
Answer
MAAB guidelines define naming conventions, modeling patterns, and style rules for automotive Simulink models. They ensure: readability, maintainability, safe code generation, and team consistency. Examples: mandatory block naming, restricted block usage, signal line routing rules, subsystem hierarchy limits, and Stateflow best practices. Model Advisor checks MAAB compliance. Most OEMs extend MAAB with their own additional rules.
61
What is Simulink Real-Time?
Answer
Simulink Real-Time (formerly xPC Target) runs Simulink models on dedicated real-time hardware for HIL testing and rapid prototyping. It compiles the model to real-time C code, deploys to a target PC with real-time OS, and provides I/O connectivity. Use cases: HIL simulation of plant models, rapid control prototyping, and hardware testing with real ECUs. Supports Speedgoat hardware and various I/O boards.
62
How does Simulink handle multi-core code generation?
Answer
Simulink's Concurrent Execution configuration distributes model tasks across multiple CPU cores. Workflow: 1) Partition model into concurrent subsystems. 2) Assign partitions to tasks. 3) Map tasks to cores. 4) Embedded Coder generates thread-safe code with proper synchronization. Data Transfer blocks handle inter-core communication. Supports: POSIX threads, AUTOSAR multi-core OS, and custom RTOS targets.
63
What is the Simulink AUTOSAR Blockset?
Answer
AUTOSAR Blockset provides blocks and tools for developing AUTOSAR-compliant SWCs in Simulink. It includes: port blocks mapping to AUTOSAR R-Port/P-Port, runnable entity configuration, AUTOSAR data type definition, inter-runnable variable access, per-instance memory, and calibration parameter support. It generates both C code and ARXML descriptions, enabling direct import into AUTOSAR integration tools like SystemDesk or DaVinci.
64
What is the difference between Rapid Prototyping and Production Code Generation?
Answer
Rapid Prototyping: generates code for experimental hardware (dSPACE MicroAutoBox, Speedgoat), priority is quick deployment and I/O access, code may not be optimized. Production Code Generation (Embedded Coder): generates MISRA-compliant, optimized code for target ECU compilers, with controlled interfaces, traceability, and certification support. Automotive production always uses Embedded Coder with ert.tlc or autosar.tlc.
65
How do you manage calibration parameters in Simulink?
Answer
Calibration parameters (maps, curves, constants) use Simulink.Parameter objects with specific storage classes: ExportedGlobal or custom calibration class. In AUTOSAR, they map to calibration PortPrototypes. A2L file generation: Embedded Coder produces A2L descriptions for XCP tools (INCA, CANape) to access parameters at runtime. Parameters are placed in dedicated memory sections (calibration RAM) for online tuning.
66
What is Signal Logging vs Data Logging in Simulink?
Answer
Signal Logging captures internal signals during simulation without adding To Workspace blocks - non-intrusive and configurable via the Signal Logging selector. Data Logging captures scope data, root-level I/O, and state data to the workspace. For large models: Simulink Data Inspector provides interactive viewing, comparison, and export. In test automation, logged data is compared against expected baselines for pass/fail evaluation.
67
How does Simulink support Safety Analysis?
Answer
Safety-related Simulink features: Simulink Design Verifier for formal property proving, Simulink Coverage for structural coverage metrics, Model Advisor for coding standard compliance, Polyspace integration for code-level safety analysis, and IEC Certification Kit providing tool qualification artifacts for ISO 26262. The kit includes Tool Classification reports, verification test suites, and user documentation for TCL qualification.
68
What is the IEC Certification Kit for Simulink?
Answer
The IEC Certification Kit provides pre-packaged tool qualification evidence for Simulink, Stateflow, Embedded Coder, and Polyspace per ISO 26262 and IEC 61508. It includes: tool classification reports (TI/TD analysis), tool qualification plans, verification test suites with results, known problems lists, and user guidelines. This reduces the effort for tool qualification from months to weeks, satisfying ISO 26262 Part 8 Clause 11 requirements.