Interoperability challenges for CAN-FD/PN Transceivers: Lessons learned from CAN High-Speed Interoperability Tests

Transcription

1 Interperability challenges fr -FD/PN Transceivers: Lessns learned frm High-Speed Interperability Tests Christph Wsnitza, Gabriel Myan, Patrick Isensee, C&S grup GmbH In 2012, Bsch has released the first versin f the -FD prtcl specificatin t fulfill the increasing demands fr bandwidth and cst efficient cmmunicatin prtcls. The first -FD transceivers, supprting cmmunicatin in the -FD fast phase at higher data rates, are already available n the market. New autmtive functinalities are required withut putting the expected interperable behavir in risk. After having addressed -FD cnfrmance testing in the new internatinal standards, ISO and ISO ; requirements frm OEMs and silicn vendrs were cllected and aligned, and test cases have been drafted and specified t enable interperability f -FD transceivers in a multivendr envirnment. The first release f the Interperability test specificatin fr high-speed transceiver r equivalent devices [1] was published in This paper disclses lessns learned frm high-speed interperability tests and gives insight int interperability aspects dealing with higher data rates cmmunicatins and, additinally, cexistent scenaris cnsidering -FD transceivers and transceivers with selective wake up capability representing used cases intended t be adpted by sme carmakers. This presentatin will cnvey a detailed verview f the new interperability test specificatin in cnjunctin with the respective test system implementatin. Autmtive standards are created t imprve quality, facilitate innvatin and increase speed-t-market, but the majr mtivatin is the csts reductin achieved thrugh multiple supplier slutins and cst sharing amng car makers, Tier-1s and suppliers. One f the main prblems that ften arises is that these standardized specificatins are ambiguus r nt spelled ut clear enugh and designers disagree n what is meant by their requirements. But the netwrk design needs t guarantee interperability f all netwrk cmpnents in rder t ensure crrect system behavir. T achieve this, sme basic assumptins are required, e.g. that the standardized cmpnents behave as expected (as standardized). If this is nt assured, ne can never knw what the 04-1 actual surce f errr in a cmplex in-vehicle netwrk system is. If there is a system f mre than ne nde, even if it is a small vehicle netwrk, the purpse f that system is nt nly t exchange infrmatin but t prvide certain system functinality. It is imprtant t have reliable cmpnents that are apprved, that actually d what they are suppsed t d. Cnfrmance tests can certainly nt ttally guarantee interperability, but it can safeguard and drastically increase the chance f interperability in a system with apprpriate test cverage. If a standard defines interperable cmpnents (i.e. des nt prevent interperability by specificatin bugs), the cnfrmance test assures that all implementatins t that standard passing the cnfrmance test are

2 mst pssibly interperable, even in crner cnditins as such situatins can als be tested in the cnfrmance test. Devices designed t the cmmn standard depend n clarity f the standard, but there may be discrepancies in their implementatins that cnfrmance testing may nt uncver. This requires the systems, frmally be tested in a target scenari as they will be finally implemented t ensure they actually will intercmmunicate as advertised, i.e. they are interperable. Interperability testing is different frm cnfrmance testing as cnfrmance t a standard des nt necessarily engender interperability with anther prduct which is als tested fr cnfrmance. What are the differences between cnfrmance and interperability testing? The basic idea f cnfrmance testing is testing t determine whether a prduct r system meets sme specified standard that has been develped fr efficiency r interperability. The basic requirement fr an applicatin f a cnfrmance test is that a specified standard exists. This culd be each kind f standard, even minr cmpany-specific standards. Even if the cnfrmance test can als be applied if nly a single implementatin accrding t a standard exists, a typical cnfrmance test is nly cnsidered in case that there are mre than ne implementatins, usually als frm different implementers. Only this fact creates a situatin where different implementatins culd be cmbined int a single system r netwrk. Only that cmbinatin bears the risk f trubles in case f deviatins between the different implementatins. Fundamentals f cnfrmance testing: T apply cnfrmance testing, a specified standard must exist. Different implementatins f a standard are existing r planned. The cnfrmance test des nt ensure the quality f the specified standard it-self; it verifies the adherence f implementatins f the standard t the standard. Interperability is a prperty referring t the ability f diverse prducts r systems t wrk tgether (t be able t interact, t cmmunicate). Fundamentals f interperability testing: Interperability is a prperty that is based n intended functinal. Relevant, if multiple entities shall interperate. Standards shall describe interperable prducts and systems, i.e. the intended functinal behavir. Cnsequently, interperability is the result f adherence f implementatins regarding the standard. Interperability Prblem descriptin It can be assumed that a slutin f a single supplier, even if it wuld nt adhere t the specified standard, is basically interperable with ther implementatins f the same kind. If all share the same nn-standardized behavir, they have a gd chance t "interact" apparently crrectly. But if anther implementatin is intrduced, a nn-standardized behavir f an implementatin might prevent the expected (specified) behavir in certain situatins that are difficult t find in system-level tests and by try-uts. Therefre, the cnfrmance test and the interperability test need t be cnsidered in case f multi-supplier slutins. If multiple suppliers create prducts r cmpnents based n the same specified standard, there is unfrtunately a certain chance t create implementatin cntaining deviatins. Of curse, each supplier has gt wn ideas n hw t realize a prduct. Of curse, all f them cnsider the specified standard. But, due t the fact that everybdy has gt a specific knwledge and a specific idea n the prduct, different suppliers may read the specified standard differently (Figure 1). Everybdy might knw that a message, a nte r a text can be read by different peple, resulting in different interpretatins. This is even pssible in very simple messages like "Buy sme bread when yu cme hme." 04-2

3 Unfrtunately, human language is very imprecise by nature: Hw much is "sme bread" 200 g, 500 g, 1000 g?, what kind f bread white, grey, sft, with wheat, grains?, what time will yu cme hme d yu have t be there at a certain time? Standard Supplier A Supplier B Supplier C missing part additinal part + The first, and maybe mst established way, is t build up specific systems ut f cmpnents t a specified standard and test the verall system fr a prper peratin. In this case, it is just assumed that the sub-cmpnents are wrking as expected (as specified). Such tests are perfrmed n the system level and typically care fr the behavir f the applicatin that is realized by a distributed system. The benefit is that such tests can be set up quite easy, by a simple mck-up. The disadvantages are that each system and each system ptin needs t be set up, needs t be tested. In additin, crner cases cannt be injected easily int a fixed system, as there are many fixed and predefined parameters. The whle system and all included cmpnents are tested in that specific scenari, withut variatin and nly with ne fixed cnfiguratin. T cnsider all design ptins and all ptential extensins f a system in the future is rather neither easy nr feasible in terms f the testing effrt. In additin, system-level tests typically d nt fcus n the crrect behavir f system cmpnents, but n the verall system. The wider the fcus is, the mre difficult it is t find ut the actual surce f errr if smething ges wrng. Netwrk Will it wrk? adapted slutin Anther ptin wuld be t check the ability t interact with all cmbinatins f devices. But, the mathematical representatin f all cmbinatinal ptins increases rapidly with mre available implementatins t a specified standard. As a cnsequence, yu can never check all cmbinatins. Figure 1: Multi-Supplier-Slutin Interperability Ways t achieve it The gal f all netwrk and applicatin designers is certainly interperability and a crrect applicatin and system behavir. T achieve interperable ndes in a system and thereby a running and stable system, different appraches are theretically applicable. The third ptin is t run dedicated tests that verify at first the cnfrmance f each implementatin accrding t its underlying specified standard and afterwards the general interperability explicitly accrding t the specified interperability tests. All implementatins are tested fr basic peratins, but als fr crner case behavirs in terms f cnfiguratin, functinality timing and fault tlerance. In that way, it can be prven that each implementatin adheres t the specified standard and that all ndes in a system can rely n the respective capabilities, ranges and limits given by the standard. In that way, als scenaris that are very difficult r nt t test in a system can be tested as the cnfrmance test intends t g t the abslute limits f the specified standard instead f selecting a single cnfiguratin and scenari smewhere in the middle f all specified limits. Furthermre, the effrts t test single implementatins are linearly increasing, far slwer than all ther types f test. Optins t check interperability: a) Check all systems explicitly in all ptential perating cnditins. Detailed tests need t be repeated fr each new system and system ptin. 04-3

4 The effrts are represented by a prduct f systems, multiplied by ptins. b) Check interperability explicitly fr all device cmbinatins. Detailed tests need t be applied fr all ptential system cmbinatins and fr all available devices. The effrts are represented by fllwing equatin 1 (Figure 2): k=n (N + k 1)! A = (N 1)! k! k=1 c) Check cnfrmance and interperability f all system cmpnents within apprpriate test scenaris. Only ne cnfrmance test and ne interperability test per device, each device usable in all systems. The test effrts increase linear, i.e. A = 2 N Figure 2: Permutatin fr 10 available devices and systems f a maximum f 16 ndes. Interperability test specificatin The scpe f the interperability test specificatin [1] is the definitin f test cases and test requirements t realize a test plan fr the verificatin f transceivers in meaning f HS-PMA [2] r equivalent devices e.g. SBC regarding their interperability, even if prvided by different manufacturers. Aim f the tests declared in the dynamic test plan is t increase the prbability f cllabratin f 1 N = number f different implementatins, k = number f ndes in a system (cmbinatins with repetitin), n = maximum number f ndes 04-4 high-speed transceivers within a system and t increase the cnfidence level in this regard. Cntrary t cnfrmance tests, the interperability tests, which are defined within the interperability test specificatin, are based n a predefined reference envirnment. Single device measurements are nt in fcus f the interperability tests. A data sheet check accrding t ISO [2] as a static test plan cmpletes the interperability test. The tests will be perfrmed within the reference envirnment using predefined settings t ensure a high level f repeatability and cmparability f the test results. The specificatin defines interperability test cases fr high-speed transceiver cntaining: HS-PMA unit HS-PMA unit with selective wake-up functinality HS-PMA unit with selective wake-up functinality, tlerant t frames in -FD frmat The interperability tests, defined within this test specificatin, are fcused n transceivers. Fr that reasn, nly a limited number f cmmn mde chkes is in use and n electrstatic discharge cmpnents are applied. The defined reference envirnments cntain wire harness and passive cmpnents (cmmn mde chkes, resistances and capacitrs) nly. Depending n the intended applicatin area fr the implementatin under test, different reference envirnments and settings are defined within the interperability test specificatin. The reference envirnments are classified in relatin t the target bit rate: 500 kbit/s reference envirnment 2 Mbit/s reference envirnment 5 Mbit/s reference envirnment Generally, the behavir f a transceiver r equivalent device can be represented by a state machine. The transitins frm ne state t anther represent reactins t certain events e.g. mde change requests, bus failures, grund shifts (r their

5 cmbinatins). The behavir described by this way is a dynamical sequential behavir. The defined interperability tests, defined by the interperability test specificatin, verify the sequential behavir f the implementatin under test in reference t the specified sequential behavir. When testing a transceiver, the behavir f the implementatin under test is bserved and cntrlled at external pints, the details f the respective high-speed transceiver implementatins are nt visible. Just phenmena, relevant fr the interperability f transceivers, are cnsidered. Abstract test methds are described by identifying the pints clsest t the implementatin under test at which cntrl and bservatin are t be exercised. Since the principle f the chsen tester architecture satisfies the pints belw accrding t ISO [3], the test methd is the s called lcal test methd (Figure 3). test system UT PCO ASPs ASP IUT LT PCO PDU SUT TCP UT SV abstract service primitive implementatin under test lwer tester pint f cntrl and bservatin prtcl data unit system under test test crdinatin prcedure upper tester supervisr Operatin mde variatin after recvery at nrmal mde, failure applicatin in nrmal mde Operatin mde variatin befre recvery at nrmal mde, failure applicatin in nrmal mde Operatin mde variatin with failure befre recvery at nrmal mde, failure applicatin n startup Operatin mde variatin with failure befre recvery at lwpwer mde, failure applicatin in nrmal mde Operatin mde variatin with failure befre recvery at lwpwer mde, failure applicatin in lw-pwer mde Operatin mde variatin with failure befre recvery at nrmal mde, failure applicatin in lwpwer mde 6 th step n fault && [wake-up via bus] 5 th step lw-pwer request (if supprted) cmmunicatin f all supplied ndes 4 th step start pint (test entry) n fault > 1.5sec 2 nd step pwer n 1 st step CH_OW OR CL_OW OR CH_VBAT OR CL_VBAT OR CH_GND OR CL_GND OR CL_CH OR lss f ne terminatin SV TCP lw-pwer f all ndes cmmunicatin f ndes nt defined 3 rd step PCO LT ASPs PDUs service prvider Figure 3: Lcal test methd as defined in ISO Interperability test cases The dynamic test plan is defined supprting three different data bit rates (500 kbit/s, 2 Mbit/s and 5 Mbit/s) while the arbitratin phase is always running with 500 kbit/s. Single test cases are gathered within seven main test cases accrding t s called test flws (Figure 4) between all pssible cmbinatins f nrmal mde and lw-pwer mde: Operatin mde variatin after recvery at nrmal mde, failure applicatin n startup IUT S U T 04-5 Figure 4: Example test flw mde change t nrmal (if required) Within each test flw, eight different failures will be applied: pen wire n high pen wire n lw shrt circuit between high and battery vltage shrt circuit between lw and battery vltage shrt circuit between high and grund shrt circuit between lw and grund discnnectin f ne terminating nde Anther three different grund shift scenaris (neutral, psitive and negative) will be in use. The grund shift will be applied at each nde against the thers, just as with the initializatin f wake-up via bus. The tests will be cnducted twice:

6 Once within a s called hmgeneus netwrk here a mix f implementatin under test and reference devices is installed and nce within s called hetergeneus netwrk here nly the implementatin under test is installed. The interperability test specificatin defines nearly 60 thusand single test cases. The crrect behavir f the implementatin under test will be verified between tw and fur times per test flw. This results in mre than 190 thusand checks per test where the high-speed transceiver has t behave crrectly. In rder t keep the verall test effrts preferably lw per high-speed transceiver implementatin, the fllwing simplificatin is defined: a) Fr high-speed transceivers which slely supprt data bit rates up t 1 Mbit/s, all applicable test flws will be executed in 500 kbit/s reference envirnment. b) High-speed transceivers, which supprt higher data bit rates (2 Mbit/s r 5 Mbit/s), are nt required t perfrm the 500 kbit/s data bit rate tests because the fundamental 500 kbit/s functinality is implicitly tested thrugh the arbitratin phase. The 2 Mbit/s reference envirnment is used fr these devices fr all test flws. c) High-speed transceivers, which supprt 5 Mbit/s, will be tested using ne test flw in the dedicated 5 Mbit/s reference envirnment while all ther tests are run in the 2 Mbit/s reference envirnment. (Ratinal fr this simplificatin is that the general functin f the device is already prven with the 2 Mbit/s test flws and the bit rate f data cmmunicatin has n impact n the main fundamental mde cntrl functins and failure recvery.) Interperability test envirnment Because f fcusing n the interperability f high-speed transceiver cmpnents in system applicatin, nt just ne single device is cnsidered as the implementatin under 04-6 test but the high-speed transceivers in their entirety in a netwrk envirnment. The transceivers are tested in their entirety f a defined number f devices in a defined standardized bus envirnment, the s called standard net, which is related t the implementatin under test. The definitin f the standard net envirnment cnsiders the mst realistic and relevant system peratin cnditins. The standard net cnsists f defined numbers f ndes, each nde cnsisting f capacitrs, cmmn mde chkes at specified psitins, implementatin under test, certified -FD cntrller and cmmunicatin sftware laying abve which implements a tken passing between the ndes including als the pssibility f multi casting messages. Furthermre, each nde has a stub, the respective length resulting frm a defined ttal wire length (Figure 5). _L _H TRX 1 l1 TRX 2 Figure 5: Standard net Industry acceptance l1 TRX 3 tken passing l2 Netwrk design has t guarantee functinality and interperability f all netwrk cmpnents in rder t ensure a crrect system behavir even if multiple supplier slutins are used. Utilizatin f standardized cmpnents, which fllws a cnscientius defined standard, is the key step t achieve the aim. The adherence t the standard itself needs t be prven. A cnfrmance test nly is nt capable t guarantee ttal interperability, but this gap is clsed by an additinal interperability test. Hwever, cmplete test cverages thrugh cnfrmance and interperability testing are useless if it ignres the needs f the autmtive industry and... standard net TRX TRX15 (n-1) TRX n capacitive lad capacitive lad capacitive lad capacitive lad capacitive lad terminatin terminatin l2

7 cnsequentially des nt find any kind f acceptance. T avid this, C&S has been actively wrking with partners in the autmtive and semicnductr industry in rder t develp an interperability test specificatin which will relish wide acceptance. Tgether with experts frm these cmpanies, the interperability test scenaris and the failures settings were discussed and afterwards defined within the specificatin. Based n the resulting interperability test specificatin, C&S has created the interperability test system. [2] ISO , Rad vehicles Cntrller area netwrk () Part 2: High-speed medium access unit, secnd editin [3] ISO , Infrmatin technlgy Open Systems Intercnnectin Cnfrmance testing methdlgy and framewrk Part 1: General cncepts Christph Wsnitza C&S grup GmbH Am Exer 19b Wlfenbuettel Phne / Fax / inf@cs-grup.de Web page: Gabriel Myan C&S grup GmbH Am Exer 19b Wlfenbuettel Phne / Fax / inf@cs-grup.de Web page: Patrick Isensee C&S grup GmbH Am Exer 19b Wlfenbuettel Phne / Fax / inf@cs-grup.de Web page: References [1] Interperability test specificatin fr high-speed transceiver r equivalent devices, revisin 00,