Auto­mat­ed builds and tests have become an inte­gral part of mod­ern soft­ware develop­ment. Con­tin­u­ous Inte­gra­tion - or in short CI - is also be.

You need to accept Cook­ies to see this Video

Every sin­gle time a devel­op­er inte­grates a code change into the ver­sion con­trol sys­tem a fast and high­ly auto­mat­ed series of steps - a so-called pipeline - is trig­gered. Typ­i­cal steps can be Build, Sta­t­ic Analy­sis, Unit, and Sys­tem test­ing (see image below).

After each pipeline run, a qual­i­fied state­ment is avail­able on how the change has affect­ed the state and qual­i­ty of the soft­ware. With­in min­utes, it is clear to the devel­op­er whether the pipeline run has been com­plet­ed suc­cess­ful­ly.

If the pipeline fails since for exam­ple the build is bro­ken, test cases fail or impor­tant met­rics are not met, rework is nec­es­sary. Errors and faults are detect­ed early and can be fixed quick­ly which is time- and cost-sav­ing. Imple­ment­ed the right way, CI can be a real pro­duc­tiv­i­ty boost­er for soft­ware develop­ment.

Although exten­sive tests can be exe­cut­ed inde­pen­dent­ly from the tar­get hard­ware, there will be a point in time when the soft­ware has to run on the tar­get hard­ware. Stubbed or sim­u­lat­ed envi­ron­ments can­not cover all the poten­tial pit­falls: hard­ware periph­er­als are not avail­able or don’t behave sim­i­lar­ly to the real hard­ware, the tim­ing behav­ior is dif­fer­ent, the cross-com­pil­er gen­er­ates tar­get-spe­cif­ic code and thus not the same code as the com­pil­er that is used for the test envi­ron­ment and so forth. This is why it is rea­son­able to start with test­ing on the tar­get hard­ware already in the early phas­es.

Work­ing with embed­ded tar­gets is always accom­pa­nied by some chal­lenges: Lim­it­ed avail­abil­i­ty of the lat­est hard­ware, eval­u­a­tion boards, and relat­ed tools like debug­gers are rare goods, and can be dam­aged quite eas­i­ly.

A solu­tion can be a setup of ded­i­cat­ed hard­ware test racks. iC7 Blue­Box Debug­gers, iC5700 CI, and iC5000 CI are acces­si­ble via USB and Eth­er­net. That allows shared access sce­nar­ios: Tar­gets are locat­ed in an appro­pri­ate envi­ron­ment and avail­able 24/7 from all around the globe. Engi­neers can access them for develop­ment pur­pos­es and man­u­al tests, the CI Infra­struc­ture can exe­cute com­mit - or time-trig­gered (like night­ly) pipeline runs.

Com­plex test cases can be direct­ly per­formed via winIDEA by using the flex­i­ble and exten­sive winIDEA SDK to imple­ment the tests. Since debug­ging tools have full con­trol over the tar­get, it is pos­si­ble to direct­ly stim­u­late APIs and ver­i­fy cer­tain con­di­tions dur­ing run­time. It is pos­si­ble to manip­u­late para­me­ters and vari­ables and thus force error sce­nar­ios via fault injec­tion.

With this approach, on-tar­get tests can be per­formed on dif­fer­ent lev­els with­out the need for any test code or test instru­men­ta­tion on the tar­get side (non-intru­sive test­ing).

winIDEA SDK offers the ideal solu­tion to give third-party or in-house devel­oped test­ing tools access and con­trol over the hard­ware and thus allow on-tar­get test exe­cu­tion. Opti­mized algo­rithms ensure high-per­for­mance and life­time-pre­serv­ing (e.g., reduc­ing flash wear-out) tar­get down­loads. The exe­cu­tion of select­ed test cases can be con­trolled and test results can be acquired and pro­vid­ed for fur­ther pro­cess­ing.

How does a code change affect the per­for­mance of the appli­ca­tion?

What impact does a mod­ule have on the run­time behav­ior of the sys­tem?

Since appli­ca­tions are becom­ing more and more com­plex and con­trollers get maxed out to their limit, it is nec­es­sary to deal with such ques­tions. With the imple­men­ta­tion of auto­mat­ed tim­ing analy­sis, it is easy to ver­i­fy tim­ing con­straints and keep an eye on impor­tant tim­ing met­rics over the evo­lu­tion of the soft­ware. Bot­tle­necks can be detect­ed at an early stage and if nec­es­sary, cor­rec­tive mea­sures can be ini­ti­at­ed. Using trac­ing tech­nol­o­gy also allows the non-intru­sive mea­sure­ment of code cov­er­age. Instru­men­ta­tion code that will affect the run­time behav­ior is not required.

With the Add-on mod­ules, all prod­ucts are also fully con­trol­lable via the winIDEA SDK, it is pos­si­ble to great­ly expand the range of appli­ca­tions in the CI envi­ron­ment.

With the CAN/LIN it is pos­si­ble to ana­lyze the com­mu­ni­ca­tion on busses in detail and par­al­lel to the soft­ware. The ADIO can ana­lyze the sig­nals of the microcontroller’s out­put pins and stim­u­late the input pins.