means that death or severe injury will occur if the corresponding precau-tions are not taken.
WARNING
means that death or severe injury may occur if the corresponding pre-cautions are not taken.
CAUTION
with a warning triangle means that slight injury may occur if the corre-sponding precautions are not taken.
CAUTION
without a warning triangle means that damage to objects may occur if the corresponding precautions are not taken.
IMPORTANT
without a warning triangle means that an undesirable event or state of affairs may occur if the corresponding information is not observed.
Certification
A quality management system to DIN ISO 9001 certified by DQS is used in the manufacture and sale of the products and systems listed in this documentation. The DQS certificate is recognized in all EQ Net countries.
Rights
SIBAS® is a registered trademark of Siemens AG. Other designations in this document may be trademarks and use of these by third parties for their own purposes may violate the owner’s rights.
The source code of the MVB-PC/104 API will be released to the user as freeware and is based on an "as is implementation". The user cannot hold Siemens liable for any claim. Sie-mens cannot guarantee that the API will operate without malfunctions and/or errors. The user has no claim to support for the use of the API. Any liability resulting from the use of the API is excluded.
The regulations for transport/export of goods must be observed as soon as techno-logy/software in the form of objects (documents or data media) is used within the scope of ’personnel deployments’ or hardware is exported or handed over for possible export.
The export marks used in this user manual correspond to the export marks of the software described. In this case:
AL: N
ECCN: 5d992B2
Contacts
Please contact the following if you have any questions about this documentation or the product described here.
5 API Functions ......................................................................................... 26
5.1 Class 1.1............................................................................................................. 26
5.1.1 Function MVBCInit() ..................................................................... 26 5.1.2 Function MVBCStart() ................................................................... 27 5.1.3 Function MVBCStop() ..................................................................... 28 5.1.4 Function MVBCGetPort() ............................................................... 28 5.1.5 Function MVBCPutPort() ............................................................... 29 5.1.6 Function MVBCSetDSW() ................................................................. 29 5.1.7 Function MVBCIdle() ..................................................................... 30 5.1.8 Function MVBCGetDeviceAddress() ........................................... 30 5.1.9 Function MVBCRetriggerWd() ...................................................... 30
5.2 Class 1.2 resp. Class 1.3 .................................................................................. 32
5.2.1 Comments about the XHUGE-define.................................................. 32 5.2.2 Function MVBCGetSpecifiedNSDB() ........................................... 32 5.2.3 Function MVBCTransferNSDB() .................................................... 33 5.2.4 Function MVBCConfigure()........................................................... 34 5.2.5 Function MVBCResolvePort() ...................................................... 35 5.2.6 Function MVBCResolveSignal() .................................................. 35 5.2.7 Function MVBCGetPortSTTH() ...................................................... 36 5.2.8 Function MVBCGetSignal()........................................................... 36 5.2.9 Function MVBCPutSignal()........................................................... 37
5.2.10 Function MVBCGetSignalEx() ...................................................... 38 5.2.11 Function MVBCPutSignalEx() ...................................................... 39 5.2.12 Function MVBCReadChecksum() .................................................... 40 5.2.13 Function MVBCWriteChecksum() .................................................. 40 5.2.14 Function MVBCGetNSDBVersion()................................................ 41 5.2.15 Function MVBCGetNSDBPortDef()................................................ 41
5.3.1 Function MVBCGetMVBMConfig() .................................................. 43 5.3.2 Function ReadMVBMConfig() ........................................................ 43 5.3.3 Function SaveMVBMConfig() ........................................................ 44 5.3.4 Function MVBCIdle() ..................................................................... 44 5.3.5 All other Functions ............................................................................ 45
6.1 The Structure of the Traffic Store .................................................................... 47
6.1.1 Process data in the Traffic Store ...................................................... 47 6.1.1.1 Port Index Table (PIT) ...................................................................... 47 6.1.1.2 Port Control and Status Table (PCS)................................................ 47 6.1.1.3 Data Area.......................................................................................... 48
1.1 About this Document For the integration of subsystems in the MVB vehicle bus, the MVB PC/104 interface module is the preferred component for installation in the control unit to be supplied. The MVB PC/104 has no firmware. The protocol stack for communication must be implemented on the host CPU. Siemens provides subsystem suppliers with an Application Programmers' Interface (API) for this purpose. The API supports the process, message and control data on the MVB.
This documentation is intended for developers who use the MVB PC/104 to implement the functionality of a TCN slave on their hardware platform. It contains the following:
• An overview of the functionality to be implemented
• Details for source code integration
• Details of the API (Application Programmers' Interface)
It is assumed that the user of this manual is familiar with the following:
• Basic principles of TCN communication: see [1]
• Hardware description of the MVB PC/104 bus interface: see [2] and [3]
• Basic principles of the MVBC ASIC (Multifunction Vehicle Bus Controller): see [4] and [5]
• For MVB-M applications (MVB in Multiple-unit Vehicles) also: see [6]
This document is valid for modules according to [2] and [3]. Only [2] applies to new applica-tions. It is valid for API Version 2.10.0 and higher.
1.2 Cause Whereas, in some applications, it is inadequate to use the MVB PC/104 as a Class 1 node when connecting to the MVB (i.e. maximum 16 words addressable, one communication part-ner only), in other applications, the full functionality of MVB classes 2 to 4 (message data, bus administrator, etc.) is not available or is not needed.
In order to provide optimum support for subsystem suppliers, a graded solution based on the MVB PC/104 interface is available with functionality between Class 1.0 and Class 2.0. These solutions are designated as Class 1.1, Class 1.2 and Class 1.3.
Furthermore, also a Class 2 base implementation is offered. The Class 2 base implementa-tion is described more closely in [7]. In this document it will not be described further.
1.3 Object The MVB PC/104 interface based on the PC/104 standard (industry standard, 104-pin bus with AT-bus timing) connects the parallel PC/104 bus to the serial MVB. This module is im-plemented as a Class 1.1 to 1.3 node using the API. Access to the memory of the traffic store is word-oriented (byte-oriented access is not possible).
The MVBC ASIC contained in the package handles a large proportion of the communication tasks. It converts the data of the traffic store to the serial TCN data stream on the MVB (and vice-versa) and contains an automatic redundancy switch in addition to error and collision detection. For further details, please refer to the description of the MVBC ASIC in [4] or [5].
Since the MVB PC/104 has no firmware, all accesses to the interface are executed from the host system. The API provides the appropriate functionality for this purpose. Special priority was given to ease of portability when programming. The C source code of the API will be re-leased to users as freeware, for integration in their own system, and is based on an "as is implementation". This provides users with a cost-effective means of integrating their own systems in the TCN system.
1.4 Remarks about the NSDB Consistent data definitions must be available on all communication partners, in order to en-sure correct communication on the MVB. All interfaces must use identical data types, vari-ables, positions, times, etc. on the necessary ports.
All data of the bus nodes are managed centrally, in order to ensure data integrity. The rele-vant data for a specific interface are extracted into a Node Supervisor Data Base (NSDB) and made available to subsystem suppliers. The NSDB is a binary file, however its contents can be converted to a text file.
It is possible to append several NSDBs and combine them in a multiple NSDB. This allows several devices to be operated with the same multiple NSDB. The appropriate NSDB is se-lected from the multiple NSDB during the initialization phase of the API.
2 API Expansion Levels For the MVB PC/104, an API exists in several expansion levels for the MVB application. It implements the functionality of a Class 1.1 to Class 1.3 and Class 2 bus node. The classes complement each other, each one using the functions of its subclasses. In general, data communication is based on process data.
In addition to the basic functions like
• Initialize MVBC and traffic store
• Start MVBC
• Stop MVBC
Further functions are made available in different expansion levels. The expansion level is defined by compiler switches or by including selected source modules.
2.1 Class 1.1 This is the lowest expansion level supported by the API. It does not use an NSDB and is thus inflexible in terms of the port information. This expansion level cannot be used for MVB-M applications.
For data communication, Class 1.1 only allows reading and writing of entire ports. Fixed data structures are used for initialization purposes. These structures must be preset by the user. The data may be extracted from the text version of the NSDB.
2.2 Class 1.2 In addition to the functionality of Class 1.1, this expansion level supports read and write ac-cess to individual signals with reference to their symbolic name. Initialization is performed by means of an NSDB that is included statically in the user system. For this purpose, a con-verter is supplied in order to convert the binary NSDB into an ASCII file, which is then in-cluded. Changes to the NSDB therefore necessitate the recompilation of the user system.
The functions required for MVB-M and multiple NSDB are supported.
2.3 Class 1.3 In Class 1.3, the user system is able to load or re-load an NSDB at run-time. Other functional differences between Class 1.3 and Class 1.2 do not exist.
Since the loading of an NSDB is specific to each platform, it is the responsibility of the user to implement this functionality.
The functions required for MVB-M and multiple NSDB are supported.
2.4 The Monitoring Concept for Process Data The MVB interfaces send process data cyclically to the bus. If the controller does not send new process data, the last values sent to the interface module are sent again and cannot be distinguished from current valid data.
In the event of a fault in the controller of the data source, it is thus necessary to ensure that the MVB interface stops sending so that the sinktime supervision system responds on the communication partner. This can be implemented, for example, by means of watchdog func-tionality (see Section 5.1.9) or by resetting the interface on activation of the watchdog of the host CPU.
The following features are installed on the receiver side, in order to monitor the process data:
• Sinktime supervision
• Use of check variables (also known as validity bits)
The user is responsible for correct evaluation and response to errors.
In addition, a host computer failure and a failure of the associated interface must be consid-ered separately and suitable countermeasures provided.
2.4.1 Sinktime Supervision The sinktime supervision (STS) monitors the actual status of process data ports, where it is assumed that process data received are valid process variables and that transmission is halted in the event of a malfunction.
The MVBC ASIC can monitor all receive ports based on a timeout. Each port has an associ-ated 16-bit monitoring counter (UNSIGNED16) in its management structure in the traffic store. Each time a port receives data correctly, the counter belonging to that port is set to the value 0xFFFF. All these monitoring counters are decremented periodically, the "basic STS interval" being configured for the device. It is thus possible to determine for each port the length of time for which it has not received data.
Some examples for the counter values at a basic STS interval of 64 ms:
• 0xFFFE: No data received for at least 64 ms.
• 0xFFD7: No data received for at least 2560 ms ((0xFFFF – 0xFFD7) * 64).
The basic STS interval is valid for the complete unit. Consequently, it should be calibrated according to the shortest sinktime of all receive ports.
The monitoring counters are initialized with 0 during the initialization routine. When a super-vised port is read, an STS error is thus indicated until the first correct receipt of data in the port (e.g. immediately after port startup in the case of long intervals).
The host software detects if the sinktime is exceeded later, as a result of a receive port fail-ure, and stops processing the relevant data. In this case, it is the task of the application to ensure that the subsystem is brought into a safe operating state by using appropriate sub-stitute values or reactions.
2.4.2 Check Variables (also: Validity Bits) Check variables are 2 bits in size and are used to indicate the validity of variables or groups of variables (see [1]). They are configured in the data message.
If a node (e.g. a gateway) can no longer send valid process data, e.g. because it does not have valid input information, it sets the check variable belonging to the process data to inva-lid.
Check variables should always be provided for process data transmitted across the WTB. Check variables can optionally be used for process data transmitted across the MVB.
How many check variables are used and where they are used is determined separately for each specific project.
2.4.3 Failure of Host Computer or Bus Interface In order to prevent invalid data from being transmitted on the bus and/or processed on the host computer, it is necessary to implement interactive hardware monitoring (between the host computer and bus interface).
Failure of host computer
A watchdog function is provided on the MVB PC/104 module (MVB PC/104 with MVBCS1 ASIC only [2]), in order to detect a host failure. If the watchdog is no longer triggered by the host computer, the MVB PC/104 resets itself to the inactive state (no sending or receiving of data).
Alternatively, the watchdog functionality can be implemented on the host system. In this case, the MVB PC/104 module must be reset (hardware reset) or the MVBC deactivated in the event of a watchdog timeout.
Failure of bus interface
The host of an MVB PC/104 module cannot register the failure of the interface directly. The function capability of the interface can be monitored indirectly by cyclic access to the traffic store or MVBC register.
2.4.4 User checksum In addition to the checksum mechanism provided by MVBC user checksum may be used in application level. Use of the checksum feature is to be defined by each project.
Two different methods are possible for checksum calculation:
• 16-bit checksum with polynomial expression x^16 + x^12 + x^5 + 1 of CRC-CCITT
• 32-bit checksum of CRC32-Polynom 0x04C11DB7
In general the checksum has to be calculated after all the variables are written to shadow buffer (with function MVBCPutSignal()). One must calculate checksum before copying the shadow buffer into traffic memory (with function MVBCPutPort()).
Exactly the same, the evaluation of checksum has to be performed after reading the ports from traffic memory in the shadow buffer (with function MVBCGetPort()) and before reading the signal from shadow buffer (with function MVBCGetSignal())
One checksum can span maximum one process data port without the size of checksum vari-able itself. The port would be monitored over the span from offset 0 to the beginning of check variable. The offset of the checksum variable - 1 is also the last monitored bit.
The choice of 16 or 32 bit depends on the type of PV-Name of checksum variable. Valid types are UNSIGNED16 or UNSIGNED32.
The checksum-algorithms are compatible with SIBAS-G Baustein (function block)
The checksum functions can be used in Class 1.2 and Class 1.3.
The flowchart below shows an application model for Class 1.1:
MVBCPutPort()
MVBCStart()
MVBCGetPort()
Process Information
MVBCPutPort()
MVBCIdle()
MVBCInit()
optional:Retrigger Watchdog
Fig. 1: Application model for Class 1.1
After the initialization and after the start of the MVBC ASIC, the system enters an endless loop. Data are received, processed and sent. At the end of the loop, the MVBCIdle() func-tion is called in order to update the device status word (DSW).
Data access is always performed with reference to the complete port.
Note: After the MVBCInit() call, the MVBC ASIC is initialized but is still in the stopped state. Bus communication does not start until MVBCStart() is called.
To prevent invalid data from being sent to the MVB temporarily, the send ports in the traffic store must be initialized by calling MVBCPutPort() between MVBCInit() and MVBCStart().
3.2 Class 1.2 Class 1.2 has the following features in addition to the functionality of Class 1.1:
The configuration data are included statically via an NSDB or a multiple NSDB. This is achieved by using b2array.exe (see Section 4.5.3) to convert the NSDB file to an ASCII hex file in C notation. The file is then included in the generation of the user system by means of an Include statement.
Application model: see Class 1.3.
3.3 Class 1.3 Class 1.3 has the following features in addition to the functionality of Class 1.2:
• Direct access to the binary NSDB data
• Dynamic re-loading of an NSDB or multiple NSDB
• User checksum (optional)
This functionality is host-specific and must be prepared by the user.
The flowchart below shows the application model for Class 1.2 and Class 1.3:
optional for multiple NSDB:MVBCGetSpecifiedNSDB()
MVBCTransferNSDB()
MVBCConfigure()
MVBCResolvePort()
MVBCResolveSignal()
MVBCPutSignal()
optional:MVBCWriteChecksum()
MVBCPutPort()
MVBCStart()
MVBCGetPort()
optional:MVBCReadChecksum()
MVBCGetSignal()
Process Information
MVBCPutSignal()
optional:MVBCWriteChecksum()
MVBCPutPort()
optional:Retrigger Watchdog
MVBCIdle()
Fig. 2: Application model for Class 1.2 and Class 1.3
The required data for port and signal accesses are retrieved from the NSDB. If a multiple NSDB is used, the matching NSDB must first be determined. A binary NSDB is transferred (MVBCTransferNSDB()) from the big endian format into the system specific format in order to initialize the system.
It is also possible, in an endless loop, to access the individual signals in a port (MVBCGetSignal() resp. MVBCPutSignal()) as well as the complete port (the latter cor-responding to Class 1.1 functionality).
The MVBC sends the data after MVBCStart(). To prevent invalid data from being transmit-ted temporarily, the port must be initialized by calling MVBCPutPort() resp. MVBCPutSignal() before calling MVBCStart().
3.4 MVB-M The functionality required for MVB-M is supported in Class 1.2 and higher if the "MVB_M" compiler switch is set. A slave detects the MVB-M mode with reference to the NDSB entries.
In addition to the MVB slave functionality, an MVB-M slave checks, during startup and nor-mal operation, whether it needs to respond to a configuration request. Please refer to the MVB-M documentation [6] for detailed information.
The flowchart below shows the model of an MVB-M application:
Here, scanning for the configuration request takes place within the endless loop, in addition to the application model of Class 1.2 and Class 1.3. MVBCConfigure() is invoked if MVBCIdle() returns MVBM_CONFIG_REQ. It is important that this branch is followed only in this case. In all other cases, the same endless loop is executed as in Class 1.2 and Class 1.3.
Note: If the interface is in the default configuration, i.e. it does not yet have valid MVB-M con-figuration data, some functions return an error. In this case, execution must continue until the main loop, where the configuration ports are received.
MVBCStart() must therefore be called even if MVBCResolvePort() and/or MVBCResolveSignal() return an error, in order to receive and evaluate the configuration ports with a configuration request. A detected configuration request subsequently leads to normal operation after a reset and conversion of the NSDB data.
4.1 Overview The API consists of the files shown in the table. The table shows which files are used for which application model (MVB class):
File Class 1.1 Class 1.2 Class 1.3
cl1_1.h X X X cl1_1.c X X X cl1_2u3.h X X cl1_2u3.c X X cl1_ret.h X X X dpr_dep.h X X X config.h X X X host_dep.h X X X host_dep.c X X X b2array.c X b2array.exe X
Tab. 1: API Files
history.txt contains a description of the various revision levels (versions) of the MVB-PC/104-API.
4.2 Compiler Switches The functionality and scope of the MVB-PC/104-API can be configured by setting and clear-ing compiler switches.
BIGENDIAN Activates Motorola format for the MVB-PC/104-API (see 4.4.2)
The MVBC is then not converted. This takes place in config.h using the constant LCX_INTEL_MODE (see 4.4.1)
CLASS2_NSDB NSDBs with entries for Class 2 can be processed. These entries are not relevant for the function of the MVB-PC/104-API, however error messages occur without this switch if the NSDB contains Class 2-specific entries.
USE_CRC Activates calculation of user checksum
Tab. 2: Compiler Switches of the API
4.3 Files Which Do Not Need to be Changed In general the following files may be incorporated unchanged into the user's system.
4.3.1 File cl1_1.h This file contains prototypes and defines for classes 1.1 to 1.3. This file is always required.
4.3.2 File cl1_1.c This file contains all functions for classes 1.1 to 1.3. This file is always required.
4.3.3 File cl1_2u3.h This file contains prototypes and defines for Class 1.2 and Class 1.3. This file is only required for Class 1.2 and higher.
4.3.4 File cl1_2u3.c This file contains all functions for Class 1.2 and Class 1.3. This file is only required for Class 1.2 and higher.
4.3.5 File cl1_ret.h This file contains the return values of the individual functions. This file is always required.
4.3.6 File dpr_dep.h This file contains all definitions and structures (DualPortRam_DEPendencies) for access to the dual port RAM. This file is always required.
4.4 Files Which Need to be Changed The following files normally have to be adapted to the system by the user.
4.4.1 File config.h This file is always required. In this file, compiler switches define the basic functionality of the API:
• Activation of Class 1.2 and/or Class 1.3
• Activation of MVB-M mode
• NSDB format (Class 2 entries)
The settings for sinktime supervision are entered here.
• Basic interval setting
• Number of docks monitored (see [4] and [5]).
These values may be extracted from the text version of the NSDB. In Class 1.2 and higher, they are read automatically from the NSDB.
Furthermore, the access mode of the MVBC (INTEL/MOTOROLA mode), the size (e.g. 64 KB) and the number of traffic stores (usually one) may be defined in this file. For Class 2, always the traffic store size of 64 KB shall be selected.
Further important settings are the arbitration mode and the number of wait states. These val-ues are independent of the type of MVB PC/104 module and MVBC ASIC. The details for modules with MVBC01 according to [3] are specified in the section "Configuration of the MVBC and TM". No restrictions for the arbitration mode setting exist for modules with MVBCS1 according to [2], however arbitration mode = 3 is the recommended setting.
LCX_WAITSTATES Number of wait states for accesses from MVBC to traffic store
LCX_ARB_MODE Arbitration mode for CPU/MVBC accesses to the traffic store
MEM_MODE Defines the size of the traffic store
4.4.2 File host_dep.h This file is always required. It contains all host-specific settings. The two most important compiler switches are:
• BIGENDIAN
• O_SEG
BIGENDIAN defines the sequence in which data is stored in memory. A Motorola CPU stores the most significant byte at the least significant address (BIGENDIAN must be defined in this case), whereas an Intel CPU stores the least significant byte at the least significant address (in this case BIGENDIAN should be commented out).
In systems operating with segmented address access, like MS-DOS, O_SEG has to be de-fined. On the other hand, in systems operating with linear addresses, like Windows NT, O_SEG should be commented out.
All other settings can be accepted without changes.
4.4.3 File host_dep.c This file is always required. It contains all host-specific functions, e.g.:
• Interrupt manipulation
• Delays
• Loading/storage of the MVB-M configuration
4.5 Additional Files
4.5.1 File history.txt This file contains a brief history of changes.
5 API Functions The following general specifications apply to all API functions:
• Since only one traffic store is used in the API, ts_id = 0 should be set.
• Class 2 should be set as the internal mode for the MVBC ASIC (see [4] and [5]).
5.1 Class 1.1
5.1.1 Function MVBCInit() MVBCInit()initializes the MVBC and generates all configured ports. After the function’s execution the MVBC is still in a halted state and does not participate in communication.
Parameters: Configuration is a pointer to a structure of type TYPE_LP_TS_CFG. ts_id is the ID of the traffic store.
Return value: MVB_NO_ERROR: Function executed successfully MVB_UNKNOWN_TRAFFICSTORE: Traffic store not initialized MVB_ERROR_PARA: Invalid parameter MVB_ERROR_NO_MVBC: No access to MVBC possible MVB_ERROR_MVBC_RESET: MVBC self-test not successful
Type definition of TYPE_LP_TS_CFG: typedef struct { UNSIGNED32 pb_pit; /* External representation of a pointer to the base address of the port index table */ UNSIGNED32 pb_pcs; /* External representation of a pointer to the port control & status field base address */ UNSIGNED32 pb_prt; /* External representation of a pointer to the port base address */ UNSIGNED32 pb_frc; /* External representation of a pointer to the force table base address */ UNSIGNED32 pb_def; /* External representation of a pointer to buffer with port default values. NULL: Initialise all port bits to '1' */ UNSIGNED8 ownership; /* LP_CFG_TS_OWNED */ UNSIGNED8 ts_type; /* traffic store type */ UNSIGNED16 dev_addr; /* MVB Address */ UNSIGNED32 tm_start; /* Traffic store base address */ UNSIGNED16 mcm; /* Memory configuration mode */
UNSIGNED16 msq_offset; /* Message queue offset */ UNSIGNED16 mft_offset; /* Master frame table offset */ UNSIGNED16 line_cfg; /* Line configuration */ UNSIGNED16 reply_to; /* Reply timeout coefficients */ UNSIGNED16 prt_addr_max; /* Port index table range is 0 .... prt_addr_max */ UNSIGNED16 prt_indx_max; /* Port range is 0 .... prt_indx_max */ UNSIGNED16 prt_count; /* The structure is terminated after prt_count elements */ UNSIGNED32 p_prt_cfg; /* External representation of a pointer the port configuration (struct STR_LP_PRT_CFG)*/ } TYPE_ LP_TS_CFG;
p_prt_cfg points to an array with prt_count elements of type TYPE_LP_PRT_CFG.
Type definition of TYPE_LP_PRT_CFG: typedef struct { UNSIGNED16 prt_addr; /* The port index table is an array of port_nr. This is the virtual connection between the port address and the port number */ UNSIGNED16 prt_indx; /* The port index defines the port to use */ UNSIGNED16 size; /* Defines the port size in bytes */ UNSIGNED16 type; /* Defines the port type (sink / source) */ } TYPE_ LP_PRT_CFG;
The entries of both structures may be extracted from the text version of the NSDB.
5.1.2 Function MVBCStart() MVBCStart()starts the MVBC. When the function has been executed without errors, the MVBC participates in MVB communication. The values contained in the traffic store are sent for source ports. These values must therefore first be initialized with MVBCPutPort().
Return value: MVB_NO_ERROR: Function executed successfully MVB_UNKNOWN_TRAFFICSTORE: Traffic store not initialized MVBM_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid. MVB_ERROR_MVBC_INIT: API has detected an initialization error of the MVBC
5.1.3 Function MVBCStop() MVBCStop()switches the MVBC to the halted state. When the function has been executed without errors, the MVBC no longer participates in MVB communication.
Return value: MVB_NO_ERROR: Function executed successfully MVB_UNKNOWN_TRAFFICSTORE: Traffic store not initialized. MVB_ERROR_MVBC_INIT: API has detected an initialization error of the MVBC.
5.1.4 Function MVBCGetPort() MVBCGetPort()reads the contents of the entire port from the traffic store. A threshold value (tack) can be passed for sinktime supervision (see Section 2.4.1). If the value falls below this threshold, the sinktime has expired.
Parameters: Port is the address of the port to be read PortBuffer is a pointer to an array in which the data are stored. Care should be taken to ensure that the array is sufficiently large. Tack is the comparison value (threshold value). Age is a pointer to a variable of type UNSIGNED16, where the actual value of the port-specific counter is stored. ts_id is the ID of the traffic store.
Return parameters: The actual value of the port-specific counter and the data of the port are re-turned in the array parameter. The first word of the array is used internally. The data start at the second word of the array. The array must therefore be two bytes longer than the port!
Return value: MVB_NO_ERROR: Function executed successfully MVB_UNKNOWN_TRAFFICSTORE: Traffic store not initialized MVB_ERROR_MVBC_STOP: MVBC not active on the MVB MVB_ERROR_PORT_UNDEF: Port was not created MVB_WARNING_NO_SINK: This port is not a sink port MVB_WARNING_OLD_DATA: Sinktime has expired. MVBM_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid.
Note: MVB_WARNING_OLD_DATA is returned even if the port has not yet been re-ceived at all.
Parameters: Port is the address of the port to be written PortBuffer is a pointer to an array in which the data are stored. The first word of the array is used internally. The data start at the second word of the array. The array must therefore be two bytes longer than the port! ts_id is the ID of the traffic store.
Return value: MVB_NO_ERROR: Function executed successfully MVB_UNKNOWN_TRAFFICSTORE: Traffic store not initialized MVB_ERROR_PORT_UNDEF: Port was not created MVB_ERROR_NO_SRC: This port is not a source port. MVBM_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid.
5.1.6 Function MVBCSetDSW() MVBCSetDSW()sets bits 21, 24 and 25 of the device status word (DSW). The user sets these bits. The meaning of these bits is as follows:
21: Device Not Ready
24: Some Device Disturbance
25: Some System Disturbance
These bit settings are project-specific.
All other bits of the DSW cannot be set (directly) by the user.
Parameters: ts_id is the ID of the traffic store. mask is a bitmask. The bits of value are only transferred if the mask bit is set. values contains the bit values to be transferred
Return value: MVB_NO_ERROR: Function executed successfully MVB_UNKNOWN_TRAFFICSTORE: Traffic store not initialized
5.1.7 Function MVBCIdle() MVBCIdle()should be called cyclically. This function updates bits 26 (Redundant Line Dis-turbed) and 27 (Line A Active) of the DSW from internal MVBC registers.
Parameters: devAddress is a pointer to a variable of type UNSIGNED16. ts_id is the ID of the traffic store.
Return parameters: The device address currently used by the MVBC is stored in devAddress.
Return value: MVB_NO_ERROR: Function executed successfully MVB_UNKNOWN_TRAFFICSTORE: Traffic store not initialized
5.1.9 Function MVBCRetriggerWd() MVBCRetriggerWd()starts and triggers the MVBCS1 watchdog. The watchdog is only available with the MVBCS1 ASIC according to [2] and [4]. If this requirement is not met, MVB_WATCHDOG_NOT_AVAIL is returned.
The watchdog is inactive initially when the power to the MVBC is switched on. The watchdog of the MVBCS1 is practical and available only after calling MVBCStart(). The watchdog is activated on the first MVBCRetriggerWd() call where trig_val is not equal to 0.
The value passed in trig_val defines the timeout. When the timeout expires, the MVBCS1 interrupts communication on the MVB and switches to configuration mode. MVBCRetriggerWD() calls after expiry of the watchdog timeout return MVB_ERROR_MVBC_INIT.
Communication on the MVB can be enabled again once MVBCStart() is called again.
Parameters: ts_id is the ID of the traffic store. trig_val is the value for the watchdog timeout The most significant bit (MSB) defines the time base: 0 -> 1 ms 1 -> 32 ms The remaining 15 bits can be used to define the timeout. Examples: trig_val = 0x0200 is equivalent to 512 milliseconds trig_val = 0x8200 is equivalent to 16384 milliseconds trig_val = 0 deactivates the watchdog with no further effect
Return value: MVB_NO_ERROR: Function executed successfully MVB_UNKNOWN_TRAFFICSTORE: Traffic store not initialized MVB_ERROR_MVBC_INIT: MVBC is in initialization mode, i.e. the watchdog has expired MVB_WATCHDOG_NOT_AVAIL: The watchdog function of the MVBC is not available
5.2.1 Comments about the XHUGE-define In the function headers listed below, for all parameters pointing to the NSDB data structure the define XHUGE is added. If you do not compile your code with the compiler switch BIG_NSDB_SUPPORT, this does not affect your code because it is an empty definition.
5.2.2 Function MVBCGetSpecifiedNSDB() MVBCGetSpecifiedNSDB() is only necessary for multiple NSDBs. This function selects a binary NSDB from a list of concatenated NSDBs (multiple NSDB). The multiple NSDB may be either a fixed included array (Class 1.2), created by b2array, or a binary NSDB stored dynamically (Class 1.3).
The pointer to the start of the selected NSDB is returned on the basis of the selection criteria Device Address or Application ID.
If the combination of selectCriteria and valueCriteria does not match any of the NSDBs contained in the multiple NSDB, selectedNSDB remains unchanged and NS_NOT_FOUND is returned.
If the multiple NSDB contains exactly one NSDB, it is selected, regardless of the selection criteria and the warning NS_WARNING_ONE_NSDB is returned.
MVBCGetSpecifiedNSDB() must be called before MVBCTransferNSDB() when using multiple NSDBs.
Parameters: multiNSDB is a pointer to the start of the multiple NSDB. selectedNSDB is a memory cell in which the pointer to the selected NSDB is stored. selectCriteria is the type of selection criteria: NS_APPLICATION_ID: Application ID which is contained in each NSDB and which can be defined when the NSDB is generated. NS_DEV_ADDR: MVB device address valueCriteria is the value of the type selectCriteria used to select the NSDB.
Return parameters:
Pointer to selected NSDB within the multiple
Return value:
NS_OK: Function executed successfully NS_NOT_FOUND: NSDB or contained element not found NS_WARNING_ONE_NSDB: Multiple NSDB contains only one NSDB
5.2.3 Function MVBCTransferNSDB() MVBCTransferNSDB() converts a binary NSDB (stored in big endian format) into the host- specific format. The binary NSDB may be either a fixed included array (Class 1.2), created by b2array, or a binary NSDB stored dynamically (Class 1.3).
The destination memory area, in which the NSDB is stored, must be provided by the user. Please ensure that this memory is large enough to store the entire NSDB, because the buffer size of the API is not monitored.
MVBCTransferNSDB() transfers only entries that are supported by the API. Other entry types generate the error MVB_ERROR_WRONG_SEQ. This is taken into account during the generation of an NSDB for the MVB-PC/104-API.
The API supports the following entries in the NSDB:
• NSDB_HEADER
• NS_SINKTIME_SUPERVISION
• NS_TRAFFIC_STORE
• NS_MVBC_INIT
• NS_ROM_NAME_BASE
• NSDB_VERSION
• NS_MVB_M_TS (only when MVB-M mode is activated)
• END_OF_NSDB
With compiler switch CLASS2_NSDB, the following additional entries can exist in the NSDB without an error message being generated:
• NS_RTP_ANNOUNCE_DEV
• NS_RTP_INS_DIR_ENTR
• NS_RTP_STADI_ENTR
• NS_ROM_FCTS_BASE
• NS_ROM_STATION_BASE
These entries are not relevant for the MVB-PC/104-API but can exist in the NSDB if they have been configured.
Parameters: from is a pointer to the NSDB to be transferred to is a pointer to the memory destination in which the transferred NSDB is stored.
Return parameters: host-specific NSDB starting at address to.
Return value: MVB_NO_ERROR: Function executed successfully MVB_ERROR_WRONG_SEQ: NSDB header error MVB_ERROR_CHECKSUM: NSDB checksum error MVB_ERROR_NSDB: Unknown entry type detected during conversion of NSDB
5.2.4 Function MVBCConfigure() MVBCConfigure()initializes the MVBC with the parameters stored in the NSDB. After the function’s execution the MVBC is still in a halted state. The MVBC does not participate in the communication.
This function is used in MVB-M applications to re-convert the NSDB data and initialize the MVBC after a configuration request.
Return value: MVB_NO_ERROR: Function executed successfully MVB_ERROR_NSDB: Unknown entry type detected during conversion of NSDB MVB_ERROR_DATA: Error in NSDB entry MVBM_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid
Parameters: SignalName is a pointer to the signal name string (null-terminated). port is a pointer to a port address. pNSDB points to the NSDB.
Return parameters: The associated port number is entered in port.
Return value: MVB_NO_ERROR: Function executed successfully MVB_ERROR_PARA: Invalid parameter MVB_ERROR_SIGNAL: Signal name not contained in NSDB MVBM_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid
5.2.6 Function MVBCResolveSignal() MVBCResolveSignal()determines the handle (PV name) of a signal.
Parameters: SignalName is a pointer to the signal name string (null-terminated). SignalHandle is a pointer to a structure of type TYPE_PV_NAME_48. pNSDB points to the NSDB.
Return parameters: The PV name is returned in SignalHandle
Return value: MVB_NO_ERROR: Function executed successfully MVB_ERROR_PARA: Invalid parameter MVB_ERROR_SIGNAL: Signal name not contained in NSDB MVBM_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid
5.2.7 Function MVBCGetPortSTTH() MVBCGetPortSTTH()determines the sinktime threshold value of a port, i.e. the limit value configured in the NSDB for the port-specific monitoring counter at which the sinktime is deemed to have expired (see Section 2.4.1).
Parameters: Port is the number of the port. Tack is a pointer to a variable of type UNSIGNED16. ts_id is the ID of the traffic store.
Return parameters: The threshold value configured in the NSDB for this port is entered in Tack
Return value: MVB_NO_ERROR: Function executed successfully MVB_UNKNOWN_TRAFFICSTORE: Traffic store not initialized MVB_ERROR_PORT_UNDEF: Port was not created MVBM_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid
5.2.8 Function MVBCGetSignal() MVBCGetSignal()determines the value of a signal from a port buffer read with the function MVBCGetPort(), whether or not the associated sinktime has expired. This function does not return the value of an associated check variable.
Parameters: SignalHandle is the PV name of the signal. PortBuffer is a pointer to the array in which the data are stored. Var points to a variable corresponding to the signal type.
Return parameters: The value of the signal is returned in Var.
Return value: MVB_NO_ERROR: Function executed successfully MVB_ERROR_VALIDITY: Checkbits indicate an error or undefined state MVB_ERROR_PARA: Invalid parameter MVBM_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid MVB_ERROR_CHECKSUM: only, if User checksum is used: checksum is wrongMVB_WARNING_OLD_DATA: Sinktime has run out
5.2.9 Function MVBCPutSignal() MVBCPutSignal()enters the value of a signal in a port buffer. This buffer can be trans-ferred with MVBCPutPort() once all the signals have been entered. A check variable asso-ciated with the signal handle is set internally to "valid" (see Section 2.4.2 and [ 1 ]).
Parameters: SignalHandle is the PV name of the signal. PortBuffer is a pointer to the array in which the data are stored. Var points to a variable corresponding to the signal type.
Return value: MVB_NO_ERROR: Function executed successfully MVB_ERROR_PARA: Invalid parameter MVBM_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid
5.2.10 Function MVBCGetSignalEx() MVBCGetSignalEx()determines the value of a signal from a port buffer read with the func-tion MVBCGetPort(), whether or not the associated sinktime has expired. Additionally to the value of the variable itself, the value of the check variable is returned. The value of the signal is returned regardless of the configuration of a check variable.
Parameters: SignalHandle is the PV name of the signal. PortBuffer is a pointer to the array in which the data are stored. Var points to a variable corresponding to the signal type. Chk points to a variable containing the check variable for the signal.
Return parameters: The value of the signal is returned in Var. The value of the check variable is returned in Chk.
Return value: MVB_NO_ERROR: Function executed successfully MVB_ERROR_VALIDITY: Checkbits indicate an error or undefined state MVB_ERROR_PARA: Invalid parameter MVBM_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid MVB_ERROR_CHECKSUM: only, if User checksum is used: checksum is wrongMVB_WARNING_OLD_DATA: Sinktime has run out. MVB_ERROR_NO_CHECK_VAR: the variable has got no check variable.
5.2.11 Function MVBCPutSignalEx() MVBCPutSignalEx()enters the value of a signal in a port buffer. This buffer can be trans-ferred with MVBCPutPort() once all the signals have been entered. A check variable asso-ciated with the signal handle is written, too, to the value determined by the parameter Chk (see Section 2.4.2 and [ 1 ]). The signal is also written if no check variable is configured at all.
Parameters: SignalHandle is the PV name of the signal. PortBuffer is a pointer to the array in which the data are stored. Var points to a variable corresponding to the signal type. Chk points to a variable containing the check variable for the signal.
Return value: MVB_NO_ERROR: Function executed successfully MVB_ERROR_PARA: Invalid parameter MVBM_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid MVB_ERROR_NO_CHECK_VAR: the variable has got no check variable.
5.2.12 Function MVBCReadChecksum() MVBCReadChecksum()reads a checksum variable from a port buffer, recalculates its value and compares that value with the one from the corresponding port buffer. Two different methods are possible: 16 or 32 bit, depending on the size of the checksum variable (PVNAME).
If an error is set, then the 1st word of the port buffer is set to MVB_ERROR_CHECKSUM. The function has to be called after MVBCGetPort() and before MVBCGetSignal().
Parameters: ChkSumHandle is the PVNAME of the checksum variable. PortShadowBuffer is the pointer to the port buffer.
Return value: MVB_NO_ERROR: If the checksums match MVB_ERROR_PARA: If the checksum spans over 0 bytes or if checksum variable is not the right type (valid: UNSIGNED16 or UNSIGNED32). MVB_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid MVB_ERROR_CHECKSUM: If the checksums do not match. MVB_ERROR_VALIDITY: Checkbits indicate an error or undefined state MVB_WARNING_OLD_DATA: Sinktime has run out
5.2.13 Function MVBCWriteChecksum() MVBCWriteChecksum()calculates a checksum variable for a port buffer and writes it to the port buffer. Two different methods are possible: 16 or 32 bits, that depends on the size of the checksum variable (PVNAME).
This function has to be called before MVBCPutPort() and after MVBCPutSignal().
Parameters: ChkSumHandle is the PVNAME of the checksum variable. PortShadowBuffer is the pointer to the port buffer.
Return value: MVB_NO_ERROR: If the checksum signal was written successfully MVBM_CONFIG_UNDEF: only in MVB-M mode: the MVB-M configuration is invalid MVB_ERROR_PARA: If the checksum spans over 0 bytes or If the checksum variable is not the right type (valid: UNSIGNED16 or UNSIGNED32).
Parameters: pointers to the parameters to be determined. pNSDB points to the NSDB.
Return parameters: All parameters are filled with the values from the NSDB. NSDBName points directly to the name string in the NSDB. This string must not be changed for this reason!
Return value: NS_OK: Function executed successfully NS_DB_NOT_AVAIL: Element not found in NSDB
5.2.15 Function MVBCGetNSDBPortDef() MVBCGetNSDBPortDef()returns the number of ports configured, as well as information about the individual ports.
Parameters: prtCount is a pointer to a variable of type UNSIGNED16 prtCfg is a pointer to a pointer that points to a structure of type TYPE_NSDB_PRT_CFG. pNSDB points to the NSDB.
Return parameters: The number of configured ports is stored in prtCount. A pointer pointing to the following array is stored in prtCfg: TYPE_NSDB_PRT_CFG [prtCount] This pointer points directly to the NSDB. These entries must not be modified for this reason!
Return value: NS_OK: Function executed successfully NS_DB_NOT_AVAIL: Element not found in NSDB
Type definition of TYPE_NSDB_PRT_CFG: typedef struct { WORD16 prt_addr; /* port address number */ WORD16 prt_indx; /* index of the port with the address above */ WORD16 size; /* size of the port in bytes */ WORD16 type; /* type of the port e.g. LP_CFG_SINK */ } TYPE_NSDB_PRT_CFG;
5.3.2 Function ReadMVBMConfig() ReadMVBMConfig()is called internally by the API functions. This function reads the MVB-M configuration stored in non-volatile memory. Since this is platform-specific, the function is provided as a simple body and must be implemented by the user.
Parameters: buffer is a pointer to a byte array in which the retrieved data are to be stored. bytes is both the maximum length of the array and the number of bytes to be read.
Return parameters: The bytes read must be stored in the byte array passed in the parameter.
Return value: MVBM_OK: Function executed successfully MVBM_CONFIG_NOT_AVAIL: No valid MVB-M configuration available
5.3.3 Function SaveMVBMConfig() SaveMVBMConfig()is called internally by the API functions. This function saves the MVB-M configuration in non-volatile memory. Since this is platform-specific, the function is provided as a simple body and must be implemented by the user.
Parameters: buffer is a pointer to a byte array that contains the configuration data. bytes is the number of bytes to be saved
Return value: MVBM_OK: Function executed successfully MVBM_CONFIG_NOT_SAVED: The MVB-M configuration cannot be saved.
5.3.4 Function MVBCIdle() In the MVB system, MVBCIdle() has the task of updating the device status word cyclically (see Section 5.1.7).
In MVB-M systems, the function also handles the recognition of configuration requests. A configuration request is valid when it is asserted for at least 2 seconds. This time must be monitored. An extra parameter is added to MVBCIdle() to meet the needs of the different platforms. It indicates the time in ms between two MVBCIdle() calls.
The first time MVBCIdle() is called, this cycle value is used internally to calculate the num-ber of function calls required within 2 seconds. The result is rounded up to the next integer value. On all subsequent MVBCIdle() calls, the cycle value is no longer evaluated.
When a valid configuration request has been recognized, the function returns MVBM_CONFIG_REQ. A branch is then required in order to call MVBCConfigure(), see the application model in Section 3.4, where the MVBC is initialized with the new converted NSDB data.
If the configuration status bit in the configuration port is set in order to announce a configura-tion routine, the return value MVBM_CONFIG_ANNOUNCE is returned. However, a configura-tion request that has been recognized as valid overwrites this value with MVBM_CONFIG_REQ.
Parameters: ts_id is the ID of the traffic store msCycle is the time in ms between two MVBCIdle() calls
Return value: MVB_NO_ERROR: Function executed successfully MVB_UNKNOWN_TRAFFICSTORE: Traffic store not initialized MVBM_CONFIG_REQ: Valid configuration request has been recognized MVBM_CONFIG_UNDEF: the MVB-M configuration is invalid MVBM_CONFIG_ANNOUNCE: Vehicle configurator sends "Configuration status"
5.3.5 All other Functions The following functions also return the value MVBM_CONFIG_UNDEF:
• MVBCConfigure()
• MVBCStart()
• MVBCResolvePort()
• MVBCResolveSignal()
• MVBCGetPortSTTH()
• MVBCGetPort()
• MVBCPutPort()
• MVBCGetSignal()
• MVBCPutSignal()
• MVBCWriteChecksum()
• MVBCReadChecksum()
• MVBCIdle()
The functions
• MVBCStart()
• MVBCResolvePort()
• MVBCResolveSignal()
• MVBCPutPort()
• MVBCPutSignal()
return that value only when the functions passed their execution without any error but there is no valid MVB-M configuration. In these functions, MVBM_CONFIG_UNDEF is equivalent to an MVB_NO_ERROR, because the function itself was executed correctly, but no valid configura-tion is available.
The functions
• MVBCGetPortSTTH()
• MVBCGetPort()
• MVBCGetSignal()
return MVBM_CONFIG_UNDEF immediately in the event of an invalid configuration. Any return parameters are thus invalid.
• MVBM_CONFIG_UNDEF designates a possible MVB-M status, and not an error.
• For receive functions, the return value MVBM_CONFIG_UNDEF is equiva-lent to MVB_WARNING_OLD_DATA. For send functions, the return value MVBM_CONFIG_UNDEF is equivalent to MVB_NO_ERROR. The user therefore has the option of supplying substitute values to the interface.
• Functions returning information, like MVBCGetNSDBVersion(), do not use this additional return value.
6.1 The Structure of the Traffic Store The structure of the traffic store is predefined by the hardware of the MVBC. That makes read and write accesses to the traffic store. Thus, the traffic store structure is described ex-actly in [4] and [5].
For a better understanding for the user, here an excerpt of it is described.
The traffic store is an array of 16-bit values (the access can only be made 16-bit-wise). For a better structure, 4 of such 16-bit values are called a Dock, resp. 1 Dock = 8 Bytes.
The addresses of the traffic store are always mentioned as relative addresses to the start of the traffic store in the following. In a real system, the base address of the traffic store has to be added to that address. The base address is defined in the NSDB.
6.1.1 Process data in the Traffic Store On the MVB, ports with the addresses 0..4096 can be defined. The simultaneous storage of all these ports in the traffic store would lead to an immense amount of memory needed. Thus, only those ports are stored in the traffic store that are needed in deed for the device to be sent or received according to its NSDB.
Therefore, we have the following data model:
6.1.1.1 Port Index Table (PIT)
At the beginning of the traffic store (address 0 relative to the base address of the traffic store) there is the Port Index Table (PIT). In the PIT the so-called Port Indices are stored. The specific port indices for a device are stored in the NSDB..
The PIT contains 4096 entries, for each possible port exactly one. With MCM=0 and MCM=1, each entry has the size of exactly one byte, with MCM=2 or greater each entry has the size of two bytes.
Example: with MCM=2, at the offset of 100h (256) in the traffic store, we have the port index for port 80h (128), the entry itself is a 16-bit value.
6.1.1.2 Port Control and Status Table (PCS)
Another element in the traffic store is the Port Control and Status Table (PCS). In it, the Properties of a port are defined (source/sink, size, actual age of the data, active page of the data buffer). The start addresses of the PCS relative to the beginning of the traffic store are different for the different MCMs:
An entry for a port has a size of 8 bytes (1 Dock) in the PCS. To address an entry for a port in the PCS, the port index, multiplied with 8, has to be added to the PCS start address.
Example: with MCM=2 the port number 100h shall be accessed. In the PIT we have the value Ch. The PCS entry for that port can be found using:
PCS = C000h + 8 * Ch = C060h
6.1.1.3 Data Area
The third important element in the traffic store is the Data area. In it, the user data are stored. The start addresses of the data area relative to the beginning of the traffic store are different for the different MCMs:
MCM Start address Data area
0 1000h
1 1000h
2 4000h
The internal organization of the data area is more complex than the one of PIT and PCS. To ensure a consistency of the data inside a whole port, even if there are simultaneous ac-cesses to it by the MVBC and the application, the data area is designed as a two-page-buffer.
In this case, always that side is read that has been designated as the "active" one. The write action always takes place to the inactive side. The active side is stored in the appropriate PCS. After the write access, the active page is changed, so that the recently written data can be read now.
A port can have a maximum size of 32 bytes, i.e. two pages for that port have a size of 64 bytes. Therefore it is necessary for the access to a port in the data area to add the port in-dex, multiplied with 16, to the start address of the data area. Doing that there has to be con-sidered that the both lower bits of the port index only have to be multiplied with 8. Besides, the active page (0 or 1) has to be considered. The exact context van be seen in the following graphic:
VP means active ("valid") page, the upper row is the binary representation of the port index, the lower row is the offset of the port in the data area.
Depending on the size of the port (2, 4, 8, 16 or 32 bytes), different assignments of the data area are possible. For a better overview they are shown here; a standardized scheme is used. It shows a detail of the data area with a length of 40h (64) bytes, which is repeated permanently, beginning at offset 0. xxxx is an arbitrary 16-bit value. The green (resp. grey) area designates the user data area in the port. The user data are always stored twice in the port, on page 0 and on page 1. One of the both pages is the active one, the other the inactive one.
NSDB Node Supervisor Database: configuration data for an interface in binary format. An NSDB file can contain one or more NSDBs.
Traffic Store Memory area with a defined structure for the data to be exchanged. For MVB, it con-tains up to 4096 logical addresses of containers with process data (source or sink) in which the complete slave frames are stored.
RTP These Realtime-Protocols are especially the protocol for the transmission of message data over MVB (and WTB). The message data, however, are not real-time-capable because they do no have a deterministic timing.
On the other hand the process data are really real-time-capable and deterministic in their timing.
9 References [1] IEC 61375-1 (International Standard) (language: english)
[2] MVB PC/104 (Hardware) Module Description, Order Number S25659-B2231-A140, -A150 und -A160, Siemens AG TS (language: english)
[3] MVB PC/104 (Hardware) Module Description, Order Number S25659-B1231-A4, -A5, -A6, -A7, -A8, -A41, -A51 und -A81, Siemens AG TS (language: english)
[4] MVB-Controller ASIC MVBCS1 Data Sheet, Siemens AG TS GT E2 (language: english)
[5] MVBC 01 - Multifunction Vehicle Bus Controller Data Sheet, ADtranz (language: english)
[6] MVB-M Documentation MVB in Multiple-unit Vehicles, Siemens AG TS GT E2 (language: english)
[7] Application Programmers' Interface Version 2.10.0 for MVB PC/104 Class 2, Siemens AG TS GT E2, =! R.0113+0704&EFT040, 28. July 2004 (language: english)
