Communication Objects
This reference collection includes Vector documentation reproduced with permission. Snippets may require configuration-specific symbols and are not all standalone programs. Sources and validation limits.
Communication Object references describe modeled services, fields, methods, events, signals and PDUs. They are not interchangeable with a raw CAN message object. Begin with the object defined by your configuration and the operation you need to observe.
Choose by task and object role
| Task | Reference starting point | Question to resolve first |
|---|---|---|
| Locate a modeled service | LookupServiceProvider or LookupServiceConsumer | Which side of the service does this node represent? |
| Locate a signal | LookupRxSignal or LookupTxSignal | Is the object consumed or transmitted in this node's context? |
| Observe an update | TestWaitForUpdate | Does any update count, even when its value is unchanged? |
| Observe a change | TestWaitForChange | Is the requirement about a value change rather than traffic arrival? |
| Inspect dynamic endpoints | SD_AddConsumer, SD_AddProvider | Does the configured service allow dynamic endpoint changes? |
Lookup, service discovery and waiting solve different problems. Finding a reference does not by itself prove that a remote endpoint is available, and observing an update does not establish a request/response relationship. Read each function's return contract rather than treating every nonzero result as success.
Define what must happen during a wait
Consider a field already holding the target value before a command. A test that checks only the cached value can pass even when the provider sends nothing. Define whether the requirement needs a new update, an actual change, a specific value, or a response associated with the command. Those conditions need different evidence.
Use a finite overall deadline and distinguish timeout from interruption or API errors. If several intermediate events are allowed, preserve the original deadline rather than granting a new full timeout after every event. The bounded-wait tutorial demonstrates this discipline for CAN messages; its numeric IDs and payload checks are not Communication Object code to paste unchanged.
Handle discovery and removal explicitly
Record which component owns each reference and what happens when an endpoint disappears. A previously acquired reference should not be treated as proof that the provider still exists. The test should have separate outcomes for configuration errors, unavailable endpoints, missing updates and wrong values.
The CANoe 12 reference for SD_RemoveConsumer and SD_RemoveProvider contains an unresolved conflict between its printed void signatures and numeric return tables. Those pages now identify the conflict. Check the installed compiler/help before depending on a return value; this site does not invent a replacement signature.
Before writing the testcase
Write down the database/object path, provider or consumer role, initial state, triggering action, required observation, deadline, error handling and evidence to keep. Then confirm the installed product, option and execution context support the chosen API. Database names used in reference fragments must be replaced with objects that actually exist in the configuration.
For additional operations, compare TestWaitForValue, AbstractSubscribeEvent and GetNrOfCOConsumers. Choose by the individual API contract; the site's historical directory names do not determine the operation's meaning.
The reference material is authorized Vector documentation. This task map and stale-state analysis are this site's editorial guidance, not a record of executed service-discovery tests.