Testing

We offer:
Conformance Tests of your CAN controller (ISO 16845 and extensions).

The ISO 16845-1 is the standardized test specification to the implementations of the CAN data link layer. With the method and the abstract test suite, described in the test specification, can be verified the compliance of any CAN implementation with the requirements defined in ISO 11898-1.

In addition to these  ISO 16845-1 tests we offer extensions that have been developed since 1995 based on our testing experience. Read more also in the section “The principle of our CAN controller tests”.

For information or a quote please contact us using the contact details at Contact!

We offer:
CAN Processor Interface Tests.

For the different implementations of the CAN protocol it is defined which features they have and how they must behave, which configuration options they provide and which status information they deliver. However the transmit and receive interface to the next higher layer is product specific.

As a consequence, for example, the amount, size, and handling of the message buffers, the implementation of optional features,  power modes and interrupt handling are implemented quite differently.

These product specific properties are described in detail in the datasheet and/or in the manual of the CAN controller.

The standardized test cases of the ISO 16845-1 assume an always identical and also simplified interface to the so-called Upper Tester (who takes over the functionality of the next higher layer).

This simplification neglects the impact of the actual processor interface on the behavior of the controller. Therefore as a supplement we offer interface tests to check the specific characteristics of your processor interface in accordance with the device datasheet or manual.

For information or a quote please contact us using the contact details at Contact!

We offer:
CAN Robustness Tests.

The common protocol conformance test is typically based on short test cases that are intentionally designed to verify specific, separated features of the protocol implementation.

In doing so it is neglected, that the behavior in the current state of an implementation, is possibly influenced by the previous states and different conditions.

Therefore our robustness tests check your CAN controller with many successive test cases. Such a robustness test runs over a long period of time that  – depending on the complexity of your module – extends partially over several days.

The test cases cover conditions and events that may be critical issues:

  • Communication with high bus load, especially with certain messages to be send/received by the communication controller under test
    -> verification by pseudo-random data at very high bus load (up to 10,000,000 frames)
    -> example of failures occurring in this context: message drop in case of high bus load or transmission blocked
  • problems with the shared memory, CAN controller and the host have different clock
  • transmission or reception of multiple messages in a row, carrying significant amount of payload
    -> example of failures occurring in this context: limitation of message handling and buffer memory bandwidth, partially dropped messages
  • message jitter – time between two frames varies
    -> example of failures occurring in this context: transmission blocked, received frame partially dropped
  • problems in the presence of noise – bit errors – over several communication cycles
    -> required is the continued stability with the ability to decode valid messages after the error bit has been detected
    -> example of failures occurring in this context: previous error detection prevents further decoding of valid frames or following frame transmission.

Sections of the test run at very high bus load are considered to build up a ‘worst-case scenario’ approach. In addition errors are created. Different parameters, such as length and coding of the identifier, length and content of the messages and baudrate are varied during the test run.

Our robustness tests can detect problems and sporadic errors, which are not detected by the standardized test cases of the ISO 16845-1.

For information or a quote please contact us using the contact details at Contact!

We offer:
Testing your CAN implementation with extended properties.

In addition to the properties defined in the ISO 11898-1, your implementation may have other properties that have to be tested.

We develop the corresponding test for you.

If you want more information, take a look at our Customer Specific Tests and contact us!

The principle behind our CAN Controller Tests.

Implementations of the CAN protocol have to be compliant with the ISO 11898-1 specification to allow proper communication in the CAN network. To proof this conformity,  C&S group has developed a test system to execute test cases based on ISO 16845-1 (test specification for CAN implementations). We have been involved in the development and standardization process of that ISO standard.

When performing the standardized conformance tests, we have questioned and evaluated test procedures and test results again and again. It came out, that the test cases of the ISO 16845-1 are no longer sufficient for many applications. To close this gap and increase the  level of test coverage, we have taken into account the development of specific test groups which deal with the processor interface and also with the robustness of the implementation under high and continous bus traffic.

Our test system was developed based on the architecture defined in ISO / IEC 9646 (standard for conformance testing methodology and framework).

Your CAN controller is embedded in a test environment where a so-called Lower Tester takes over  the functions of the the OSI layer below the controller and thus handles the ‘bottom’ interface of your CAN implementation.

Accordingly, the Upper Tester takes over the functions of  the OSI layer above your  CAN controller.

The execution of the tests is controlled by our test control software. The data storage of testing results, as well as, their evaluation are done automatically.

It is also possible to carry out single tests manually while changing the settings of  the test procedure – such as the CAN message. This allows us to react to inconsistencies during test execution and to identify and analyze possible errors in the controller.

News

Successful assessment of our QM system.

On March 10, 2017, we had a representative of the DAkks in our office, who has carried out a monitoring report on our cu

Read More

We were at the “Automotive Ethernet Congress” on the 7th of February 2017

This year „Automotive Ethernet Congress” took place in Hilton Munich Park near the English Garden in Munich. Like la

Read More

Presentation at the iCC in Nuremberg on March 8, 2017

On Wednesday, March 8th, 2017, our employee, Christoph Wosnitza, gave a presentation on "Interoperability challenges for

Read More
Load More News