so, it's seem that I am going to understand the a few points
I have already modified a C-Grammar tool that I have written a few months ago (in order to do "inter modules dependencies"), just to automate the process of changing the if-statement (1) into (2)
(1): if (A && B) ----- automatically transformed into ------> (2): if (A) { if (B) {} }
* * * my boss * * * has said that he assigned a level-B (sub)task to me not because I am qualified as level-B-developer/tester (as I am still level-E), but because "I am good" at creating tools in order to solve a problem.
as far as I understood, I am working on a piece of code that was originally created for a level-D in where VectorCast just needs to check if the if-statement was taken or not, it didn't matter about the True-table, and they want to "improve" it into level-B, modifying as it's needed
var.A var.B then-branch
------------------------
False False not taken
False True not taken
True False not taken
True True taken
True table, coverage, Level D..E
var.A var.B then-branch detailed conditions
-------------------------------------------------------
False False not taken with var.A=False, var.B=False
False True not taken with var.A=False, Var.B=True
True False not taken with var.A=True , Var.B=False
True True taken with var.A=True , Var.B=True
True table, coverage, Level A..B
coverage, Level C=?!?!?!?
i am working on a draft version, which means it has passed the "normal" condition on real hardware and it's ready to be tested with "abnormal" condition, which also implies hard stress tests
as far as I understood they want to reuse (of course improving them as need) their ATP (test plan) to the ICE test, this requires "hard points" in the source code around the if-branches to allow the ICE (in circuit emulator) to collect the environment while the software is running in run-mode.
VectorCast tends to make the code "instrumented", this means modified to collect "triplets" (sampled detailed conditions) about the if-then-else statement, and also it requires debug mode, so the clock is scaled 1:x, and sometime too much intrusive
They got requested to provide a VectorCast test report (ATP), it's a MUST DONE (required by QA dudes), but they also want to provide an ICE ATP (not intrusive, but not directly requested, so it's a sort of intenral ATP): both of them requires the source code modified as my new tools is going to do (my boss justified that it costs the less, by several number of magnitude in term of dollars, than asking VectorCast-dudes to create such a tool, even if … you can't absolutely use an internal tool to do certifications, it's just for your personal engineering purpose)
Technically speaking the ICE ATP is performed with a WindRiver ICE for PowerPC440/460, it's phisically a "black box" (like a jtag-black-box but with an RJ45 plug) with a sort of hardware debug port (it's not jtag, it's not BDM, it's not NEXUS, I do not know what it is, I have no manual here, and no time to investigate, I am waiting for the first occasion to ask to an "hw" dude as soon as he will have his coffee break), with a Gigabit/sec ethernet port and up to 256Mbyte of DDR ram, able to collect thousand and thousand of triplets without breaking the CPU on hardware and software "breakpoints".
Other testes require the use of a Digital Oscilloscope (DSO), plus a test-case software (special ATP+ATR, hw dependent)
my apologies to who is heart sensitive, it's not easy to hear for me too
edit: I forgot
Last but not least, it seems that level B has the ARINC (419/429/575/573/717) interface cards with 32-bit FPGA Protocol Engine, fully configurable Bit Rate, Bit Encoding, Word Length, Start/Sync and Stop Bits. This part is covered by an other squad, a part of them has also to verify the MIL-STD-1553 compliance
So about the quality, there are a lot of people involved into the product life cycle, I do not have the full view of the process: do not take my words as THE measure of the quality in Avionics