simulate autosar basic software services and run-凯发k8网页登录

configure calls to autosar basic software services

the autosar standard defines basic software (bsw) services that run in the autosar run-time environment. the services include nvram manager (nvm) diagnostic event manager (dem), and function inhibition manager (fim) services. in the autosar run-time environment, autosar software components typically access bsw services using client-server or sender-receiver communication.

in your autosar software component model, to implement client calls to nvm, dem, and fim service interfaces, you drag and drop preconfigured nvm, dem, and fim caller blocks. each block has prepopulated parameters, such as client port name and operation. you configure the block parameters, for example, to select a service operation to call. to configure the added caller blocks in the autosar software component, you synchronize the model. the software creates autosar client-service interfaces, operations, and ports, and maps each simulink function call to an autosar client port and operation. for more information, see , , and .

here is a throttle position integration model, which integrates two throttle position sensor components and a throttle position monitor component. the sensor components take a raw throttle position sensor (tps) value and convert it to a tps percent value. the monitor component takes the tps percent values provided by the primary and secondary sensor components and decides which tps signal to pass through. the sensor components call bsw nvm and dem services, and the monitor component calls bsw dem services.

open_system('autosar_bsw_presim');

sensor components autosar_bsw_sensor1 and autosar_bsw_sensor2 each contain an initialize function block, which calls the nvm service interface nvmservice. the calls are implemented using the basic software library block . each block is configured to call the nvmservice operation readblock. the readblock calls use client ports s1lowsetpoint and s2lowsetpoint. here is the initialize function block for autosar_bsw_sensor1.

here is the nvmservicecaller block dialog box for the readblock call in the initialize function block. for more information, see .

sensor components autosar_bsw_sensor1 and autosar_bsw_sensor2 each contain two calls to the dem service interface diagnosticmonitor. both calls are implemented using the basic software library block . each block is configured to call the diagnosticmonitor operation seteventstatus. the seteventstatus calls use client ports s1stucklow, s1stuckhigh, s2stucklow, and s2stuckhigh.

here is the diagnosticmonitorcaller block dialog box for the stucklow call in the first sensor component. for more information, see .

monitor component autosar_bsw_monitor contains a call to the dem service interface diagnosticmonitor and four calls to the dem service interface diagnosticinfo.

here is the diagnosticinfocaller block dialog box for the tps1stucklow call. for more information, see .

if you have simulink coder and embedded coder software, you can generate c code and export arxml descriptions for the nvm and dem service calls. open and build each component model. for example, to build model autosar_bsw_monitor, open the model. press ctrl b or enter the matlab command slbuild('autosar_bsw_monitor').

to see the results of the model build, examine the code generation report.

configure reference implementations of autosar basic software services for simulation

to simulate an autosar component model that calls bsw services, create a containing composition, system, or harness model. in that containing model, provide reference implementations of the nvm, dem, and fim service operations called by the component.

the autosar basic software block library includes an block and a block. the blocks provide reference implementations of nvm, dem, and fim service operations. to support simulation of component calls to the nvm, dem, and fim services, include the blocks in the containing model. you can insert the blocks in either of two ways:

to automatically insert service component blocks for a model that calls bsw nvm, dem, and fim services, open the model (or a containing model) and create a simulink test test harness (requires simulink test). for more information, see (simulink test). creating a test harness compiles the model, adds the service component blocks, and creates ports and other elements required for simulation.

this example manually inserts service component blocks for nvm and dem service calls. open the integration model autosar_bsw_presim. using the library browser or add_block commands, or by typing block names in the model window, add the nvram and diagnostic service component blocks to the model.

open_system('autosar_bsw_presim');
add_block('autosarlibnvm/nvram service component','autosar_bsw_presim/nvram service component');
add_block('autosarlibdem/diagnostic service component','autosar_bsw_presim/diagnostic service component');
set_param('autosar_bsw_presim','simulationcommand','update');

the nvram service component block has prepopulated parameters, including run-time environment (rte) parameters and nvram properties parameters. examine the parameter settings and consider if any require modifying, based on how you are using the nvm service operations. for more information, see .

the rte tab table lists component client ports and their mapping to nvm service block ids. each row in the table represents a call into nvm services from a basic software caller block. calls that act on the same nvm block typically use the same block id. this example maps the nvm readblock client ports to different block ids.

the initial values tab table lists component client ports and their initial values for simulation. the default initial value is 0.

the diagnostic service component block has prepopulated parameters, including rte parameters and dem counter-based debouncing parameters. examine the parameter settings and consider if any require modifying, based on how you are using the dem service operations.

the counter-based debouncing parameters control the counter-based debounce algorithm provided by the dem service reference implementations. during multiple simulation runs, you can tune event step size and threshold parameters and observe the effects. for more information, see .

the rte tab table lists component client ports and their mapping to dem or fim service ids (in this example, event ids). each row in the table represents a call into dem services from a basic software caller block. calls that act on the same event typically use the same event id. this example maps the dem seteventstatus client ports to different event ids, and then maps the dem geteventfailed client ports to event ids that are shared with seteventstatus ports. for example, seteventstatus port s1stuckhigh and getfailedevent port tps1stuckhigh share event id 1; s1stucklow and tps1stucklow share event id 2; and so on.

simulate calls to autosar nvm and dem services

after configuring nvram and diagnostic service component blocks in the integration model, simulate the model. the simulation exercises the autosar nvm and dem service calls in the throttle position sensor and monitor component models.

open_system('autosar_bsw_simulation');
simoutintegration = sim('autosar_bsw_simulation');

related links