 in the previous session we have seen some of us of testing in terms of how the model's are organized taking an example of a model it is getting partnered in the existing testing so we have detailed about each com modules or components how is aggregated or integrated at a higher level. Then we discussed about the setup, host and target how it looks like, what will be the host based development at testing, what will be the target based development at testing, so what is the likely environment, so what is the system that is going to be used and the system with the realistic input from the system perspective, then we have seen through some of the target based retrievering techniques with the help of simulation, evaluation, target monitoring, simulators, simulators, simulators, simulators, simulation, what are the emulation techniques that are used, then we have the target monitoring, where the monitoring program will look into the target events and the data is also tracked with the target, so the tools and usage also discussed how should be used, I think today we will go through some of the commercial tools as an example, we will come to know, so these tools, basic tools which we had listed out in the earlier class, of course we went through some of the embedded systems or embedded words, we need to be aware of these words, so the next session we will take up, in this session I will provide you few questions that you can take it out, but with few questions on what we had studied in the previous class, the first one is about why simulators cannot be used for the complete testing, what is the major difference between simulators and emulators, so we just need to tell why it cannot be used for the complete testing, what is the major difference between simulators and emulators, why do we need, we all know about EST system testing setup and configuration also, why it should be called, then the last one being to provide every type of system testing, what is the major difference between simulators and emulators, so these are some of the next questions for the previous lecture, okay we will move on to the next one, the first slide of this lecture, we will discuss about PM method, we have seen several approaches, generally way of how to create test cases, test design and test approaches, energetic way, we have seen different examples and all that, there is one unique way of definition that they have used basically defined by Bart Brookman and Edwin Norton book, there is a book called testing embedded software by Bart Brookman and Edwin Norton book, you can download or you can google it, it is a good book about a PM method, basically what chapter he has discussed in detail about that, PM method, there is another method of embedded testing, so I had highlighted some of the points of that book, we will walk through that and in detail you can go through that book and we can see the differences of the general and the PM method, okay, testing approach difference for embedded system, we know that different embedded systems will have different approaches, it could be a computer electronics or it could be a home experiment or it could be an automotive or a telecom or aerospace or whatever, there are different varieties of embedded systems that are used, of course there are different test approaches and methods that is also followed, there is no unique test approach that is available, I would say if you take up two embedded systems testing over a period, the approach will be definitely different, the approach in the sense the basic criteria or the uniqueness between two embedded systems are not considered, so I would say there is no unique test approaches that is being addressed for doing this, example testing a mobile differs to testing a breakable system, you know mobile is a small device like O1, O2 major processors or couple of interface devices and breakable unit system is one of the major component that is having complex algorithms, complex interfaces will be used in a car, let us say, so definitely the testing approaches will be different in these two, so we cannot apply some method I have defined for testing a mobile and the same method I will use it for breakable unit, I do not have a unique approach but when you take, when you go through the approach that we have used, I do not know some of the final elements of this approach, definitely there are some similarities, similarities in the sense that when we are testing it we will result in either issues or we will rework in terms of this case or designs in terms of fixing the failure or retesting it, whatever it is, there are nothing but issues and the solutions for those issues in the embedded testing methods. So these similarities are cleanly organized as a structured that is nothing but TM method, TM method is nothing but organized way of embedded testing having identified the similarities of different embedded systems. So these are some of the definitions that are used, definition TM is a method that helps to assemble a suitable test approach for a particular system, that means we will define some of the structured approach from there, we will draw or assemble some test approach which will be suitable for a particular system. It provides a mechanism for assembly, suitable dedicated test approach for the technical elements applicable to any test project and set of specific measures given to the object system characteristics of the embedded system. So what it means is it provides a mechanism for accessibility, that means we have a generalized structured approach so we will pick up a suitable dedicated test approach for the technical elements which could be applicable as a result for mobile device or car device whatever it is. So it could be any project within the embedded system for a series of devices and forward by that we use the specific measures relevant to the object system. So what we do is basically we identify some of these similarities or it is called a characteristic. For these structured characteristics there are specific measures that will be used in the embedded system. So these two are very important. One is characteristics of the system, then specific measures that are required for the particular system. So these are very important while taking the TM method. So this is what the definition of TM method. This is clearly defined about the TM method approach document inside the book by Bart Rokman and Edwiga Nortonbaum. Okay, so let us go into the TM method overview. So what is a structured embedded testing method? So structured testing comprising of the four elements that is life cycle, intersection, techniques, all the elements are structured. That means life cycle, intersection, techniques and all the elements are also called as short form or lethal. So these four elements are structured. It can be TM method. We can create a diagram which explains the overview of lethal. That means that is indicated as the approach of the technical elements and testing measures and is set in the previous slide. So all these are related to the cornerstone of the structured testing. The structured testing of the TM method is basically based on these things. So what we do is we will define the TM method. We will use the specific measures of the particular system that we will apply using a mechanism called lethal. It is life cycle, intersection, techniques and all the elements. That will contain a method called dedicated test approach. So this is what is the overview of TM method. We will take up each of these lethal, life cycle, infrastructure, techniques and all the elements. What is life cycle? This defines the which activities have to be performed at what order. It gives testers and managers the detailed control over the process. We will have a separate on the life cycle in the next or the forthcoming classes. That will detail about life cycle, different testing life cycle models differently. But in the short form, the life cycle defines which activities have to be performed at what is the process, what order it has to go. There is a thing called entry and exit method. That will define all the objective outputs and the process items. So basically the life cycle uses desired control for managers as well as the testing team. Or the overall process of the entire testing. Next is the techniques. This helps with how to do things by defining standardized way to perform certain activities. That means techniques will identify how to do the testing by defining some of the standardized for testing activities. Once we have these two, then we will have the infrastructure. That is for the above techniques. What is the needed environment? So what is the infrastructure that is needed? So this defines what is needed in the test environment to make it possible to perform the planned activities. At least we have defined the plan here. We have defined the technique and what it needs to use these techniques. So what is the infrastructure element defined by the team. Once these three items are there, then we are going to have another one called organization. This basically defines the roles and required expertise of those who must perform the planned activities. The way they interact with the other techniques. That means the organization defines the various roles and responsibilities of required people for conducting the testing. So that will basically identify different people or expertise or who is required. So in the above three things we have defined the plan, we have defined the technique and we know what infrastructure is required. Once these three are laid out, we need who has to do all this. Who should do what actually? Who should do the testing? Who should do which functionality test? Who should do what? So all these things will be covered under the organization. So this is a very important basic thing about the team method. Life cycle technique infrastructure is called LITO. Once again I will go through the previous slide. Why because? To make it clear that LITO is a an outcome of the team method which will be applied for the test, the embedded test under subject. So for LITO basically we will have specific measures for the particular identify type of system and there are generic approaches on the protection of people. Combining together we will come up with a mechanism for these two basic elements. That mechanism will work out with LITO but life cycle technique infrastructure and organization. So these four are how what is being detected in this figure. Figure 2.2 is nothing but actually this is a reference to the book which I was telling just now. Testing the embedded software by Bob Blockman. I think they have put the references and I can note out this. Four core components important items of the team method. Life cycle technique infrastructure organization. Life cycle is whole organization infrastructure is supporting it. Technique is the next thing. Then we have the organization surrounding this life cycle this will be organization. So let us go in first step having the little details about life cycle. In the life cycle model the principle test activity is divided into five phases. What are the five phases? We will tell in the next slide. So basically the life cycle model is given by in addition to the phases of planning and control specification and execution completion phase has been done around the test process and to formally deliver the test phase for the organization so what it tells you it will basically provide the different phases and in addition to that it will also help in planning and control specification and execution. This is a complete phase having a different elements so basically the outcome of this life cycle to identify the outputs that are come as a satisfactory result of the testing. So what are the five phases that are defined on life cycle? The preparation specification, execution completion there is four all under one box called the PNC that is the thing about planning and control. So there is a the preparation phase where this are prepared or the test planning is done then when the test planning is done we are going to define specification that will identify all the test case test scenarios and all that. Then once we have defined all the test cases and the execution we will do the execution with the help of the third phase then the last one is the completion that means there is nothing but reporting the result capturing logging and all that the mechanism is part of the completion have So all together this will be done under the one phase which will be throughout the four phases is called planning and control So five phases of life cycle are basically divided into preparation, specification execution, completion all being compressed under the planning and control and anything okay fine okay lets go into the next one that is nothing but techniques. So what do we do with the techniques as we said all the testing methods testing mechanisms all have to be defined under this common stone supports the test process by offering testers elaborate proven and university working methods as well as enabling the management that is auditors are supporting the team to track the progress of test process evaluate the results that means techniques element will have test process in terms of testers elaborating a proven method or university working method for testing the complete embedded system so this will also help how it can be helping the management or the quality team to track the progress of the testing process and evaluating the outcome of the test in principle one or more techniques can be devised for every type of activity the testing is basically devised different activities manual automatic and white box black box etc so all this can have devised techniques these techniques are developed in the world almost every day whenever an activity exists so it will be repeated for the future test process to be supported by devising that means we have several techniques and all that so we are going to have all under this techniques method which will be used for tracking and monitoring the testing process so this is all part of the technique so this can have any activity that is part of the test process in terms of defining testing etc all that will be part of the technique and of course we can define techniques to have safety analysis in addition I am telling about basically this will help the complete picture of the testing test design test automation test data it could have process and checklist etc so all this can be part of the technique so that is about the second one so we have first corvostone and life cycle as techniques so far we have defined the life cycle we have defined the techniques and now the infrastructure that is required for implementing the techniques the infrastructure for testing includes all the facilities required for structure testing but that is nothing but tm method it can be divided into facilities needed for executing the test this is the test environment or test method sorry that the facilities that support execution tools support tools any automation any batch execution all this will be part of the test environment or infrastructure it can also include the facilities for testing staff that means the staff the testing staff their needs or or any internet or any support tools anything that is needed for the embedded testing to be carried out efficiently that is what is the infrastructure items that are required and that can have hardware software it can have a test database any equipment that is needed broad categories that book will talk about that maybe we can touch base this method in a different class dealing out each of the elements under the infrastructure of the environment for the support staff can also be part of this infrastructure coming to next user organization now we have different lifecycle technical infrastructure having said that all this are in place documented or available now who should do this how it is organized with different roles and responsibilities for various people it is all about all about people and how they communicate it is not just enough to have people assigned there should be a mechanism how people interact helping each other or reporting or strategizing like a teamwork and mostly the embedded testing will be done by an independent team in any of the organization to take up automotive or aerospace because the independent team basically get unbiased testing is not a straight forward task that can be performed with isolation unhindered by services for automotive outside world the involvement of many different clients contracting interests unpredictability shortage of expertise and time constraints when you set up and management so basically this tells about what are the various integrity details that are involved for having an organization having various types of people what are the challenges that people will have whether the people or other team that is going to do an embedded testing is having a sufficient expertise or any a certain guy having expertise or interest in certain area he should be allocated accordingly and so what do you think that he can have he may have some new plans at all all this will be configured for making this organization complete there is about a little so some of the points mechanism for making the certificate that we know basically so far it explained the principle of what it is that makes the system special it means we will define some of the characteristics we know that we first identify the characteristics then for testing those characteristics we need to have test approach that is nothing but dedicated test approach it is important to know that the TM method does not aim at achieving actually accurate and complete taxonomy of embedded systems rather its purpose is entirely practical purely from the test perspective as I said the test approach and the methods that are being used have to be purely from practical so we just cannot define some test days and say that all this have to be tested and results will come so we need to visualize from practical that is very important I will just underline few things that are very important for doing the embedded testing characteristics that means bigger picture have to be there for the system which we have that test once we identify that characteristics of that system that is used for making us writing the test approach another thing is it should be very much practical whatever we write test case or test procedure have to be realistic and practical we cannot have something which cannot be tested some sort of values suppose sensor is supposed to take something like 20 degree to 180 degree of import and it is limited with active port we cannot afford to point from minus 100 degree or 300 degree centigrade so we should see all this practicality of that particular sensor and test approach and it should be purely defined and have the ownership of the test it is from the testers perspective because he is going to test it that is why it is very important to have this taken in place for TN method so it will also help in like what makes the system special and what must be included in the test approach to tackle this so the system he has understood he will know what is making this and what should be included to make this system testable so these are some of the few key items that needs to be understood before TN method we will talk about this okay so we said that there are few characteristics or the complete characteristics of the test to be used once we have that characteristics we are going to have measures measures is the thing what is the test approach how we are going to do for that characteristics some of the characteristics that are usually used in any of the embedded systems or as below all these have to be considered for doing the embedded system testing safety critical systems technical scientific algorithms autonomous systems unique system one shot development along input and output or mix system behavior hard real-time behavior extreme environmental conditions so these are some of the definitions you have covered first by embedded systems course or the taxonomy of the embedded systems like we know safety critical systems aerospace or automotive so which have to be safe because it is very important that the systems cannot then there are certain systems having technical or scientific complex algorithms those related tests also we have to devise testing methods so the other characteristics is autonomous systems which will be having its own interactive property or defined methods of interpretation one shot development or rapid development kind of system which will be used in a short cycle then we have systems with unlocks purely with unlogged inputs unlogged outputs of course this pretty is not a study here because most of the are almost all the embedded systems so it does not mean that unlocks will be there always this is one of the and any hardware limitations or restrictions that are to be considered and state based behavior like different states system can be done or and any hardware type behavior like you know higher what is hardware type systems something like medical level which are scanning human we have a hardware type behavior because it cannot afford to miss the deadline otherwise it will result in any of the damages to the human and of course we have control systems which are for whatever it is multiple driving systems and there are systems like application they use they also have to be considered these are some of the characteristics that are used in PMO method so these are very important things that needs to be considered for developing approach example for one-shot development I would say the systems which cannot come back or it cannot be repaired also called as one-shot development so satellites which are launched only once and cannot be maintained we cannot maintain it very difficult but nowadays there are several which will help or support in terms of operating software at all but in generally these kind of systems which are released cannot be used for maintenance that is about TIM method we know that TIM method has four corner stones and with the help of these four corner stones like cycle techniques we will divide the TIM method and before we develop these techniques we use specific measures below once of course there are other things which are difficult in the book may be I will touch base in between that is possible they they use it yeah I think we can touch base one of the questions so there is a question for TIM method we can make a note about normal embedded system testing so we have gone through normal embedded system testing earlier in the software test case how very unique or different than the general embedded system testing so that is about TIM method we have gone through the various embedded system approach for all that so I would like to categorize for embedded system testing some of the tools how they are being used or how they are organized basically for embedded systems so these are some of the master tools that has to be there of course the same tools can also be used the categories are something like this test equipment test equipment logic analyzers we have different master tools used for test cases test procedures there are various versions that test development team need to need to do it like winmarch or beyond compare these are some of the tools I am just writing the examples destroy multimeter etc this much tool is something like in march beyond compare then we have static analysis metric tools such as for C++ C then we have bugzilla testing defect management tool something like bugzilla etc so many others next we have text editor tools not bad++ text pad you can use it for evaluating test results and all that so not only it is used for development it also can be used code checker is something like quality they use checking the code here code checking is not that see it or add or whatever the language checking it is something like alignment and as per the coding right lens it is there or not so this will cover basically of course we have rules coding rules something called see 2004 and 2011 also will come not sure about that but these are some of the stringent guidelines that they follow for validating that we use some of the code checker tools from telelogic and all of them so we know that IDE like IR, workbench clips then we have lotterback multi what is that multi, lotterback IR, workbench etc of course we have code compressed to the TI also used text editor some of the binary or you know there is a raw file and all that you want to do it you need text editor or text viewer tools are there so there are tools and for reverse engineering you can use that tools so you can understand which will have the called mechanism which will be used for reviewing and all that so it will be very useful to have reverse engineering tools the more the system the more complexities better to have a control on the system through some of these kinds of identifications or how the code is structured or how the models the system is so this will help basically this assembly tools usually are in built up which will disassemble the object code basically then we have dynamic analysis to runtime profiler and profiler part of the stack trace etc time machine so like this there are various tools but basically these are some of the categories that are commercially used for a software testing there could be some manual tools also which will be developed that is need basis there are other tools like static analysis and that is covered then for complexity measurement use is one of the important thing that needs to be done in embedded system we cannot have certain amount of complexity going up for the embedded system it has to be limited it is called make a complexity they use understand c c++ is one of the good tool they use it analyze the complexity of the code then dynamic analysis tool we said that time machines are all used so these are some of the commercial tools category I had put an excel sheet covering some of the embedded system tools that is used in the industry as an example so do not take it as it is used certainly in certain project or product just generalized as an example so we can just have a look at how it is I hope you will see and it is shared okay so this test basically this out tools and automations and what are the tools that is being used in different phases I have covered for all the phases of the embedded system development phase conservation phase we use visibility and project tracking was a management these are some of the phases and each phase will have different activities like development phase we have requirement management code development requirement support in the configuration we have configurable items and deliverable artifacts that test cases we develop and if it is a model then model based the coverage model based testing we do testing in coverage we take care debugging is also used as one of the testing technique reviews will be using it and then it is static static analysis etc and we have for reviews code review each step is that we use for reviews that also is one of the activity then we have a traceability traceability for test cases scenarios both upstream and downstream I will tell you what is upstream and downstream in all the class and traceability is very important about it is not just testing the test cases it also needs to be done so that we have a coverage of the testing for all the required requirements there is nothing but the plan or this plan I would say software plan and for project management and tracking we use this 10 different management artifacts now coming to tools what are the tools used for development phase then we have rectify then for code development we use the MPC series target or evaluation board MPC is involved in the power PC series from free scale we use for development debugging the ID integrated development also there is adjustment this is just an example it could be different for different embedded systems and for requirement support we use capturing all the requirements making tabulator and all that we use makers of copies word excel or visual and for design and all that of course we use visual or any of the design tools so it is also listed next to this for configuration this is very important aspect of the embedded systems the items which are under test which are under development are going to be configured they should be controlled so that will be done with the help of 7 dimensions or SVN sub portion test cases we know we use we have discussed in excel sheet for having the test cases identified for model based coverage we use MPC we use some of the model based testing model test cases we use SCADE QTE Qualified test environment for testing and coverage it is not rational this is one of the good tool they use it of course there are other tools like ldaa webcast etc debugging we use the same ID is being used development cycle of course we have a review using review cycle process with the help of SLG analysis can also be done with help of Microsoft office stack analysis this is to one of the important thing that have to be tested stack that is nothing but the memory aspect of the system that is running how much stack it is using what is the maximum it can reach and whether it is clearing it or editing the stack etc of course for reviews as a separate phase we have C reviews C and C++ code reviews QEC Source monitor core code for analog language we use PC for logic also is there for analog language reviews feasibility is one of the important aspect of this you can either automate scripts for the test cases whatever to cover it and as I have put up the script you can have the world or excel sheet report so that is what I have mentioned you can automate with the help of Python or Python to extract the data and populate the feasibility shape so basically all it is cases and procedures they will have a unique ID those unique ID are used to develop the feasibility with the help of other tool such as Python or Parl scripts that are being used to develop it for test defects and management we use test link and bugzilla maybe we will have a separate session how it looks and how it is getting used and also there are possibilities that SVN and JIT also can be used for test defects and test management so these are some of the tools that are used for the technical embedded system so this is very specific so you don't have to get biased with this I have listed out as an example so that is about the commercial tools categories in general and an example of commercial embedded system development and testing tools so again in this session I think we will have words which we have gone through so this will be growing all the time test harness, test bed, test bench automatic testing command model based testing test drivers 40 bits of MCDC, test hook boot software or boot loader boot output, ICD interface control document breakpoint, simulator, emulator placing refining and data sheet last time we stopped with this now today I have equipment or we can say test equipment which will have the necessary test environment items as elements part of the test equipment it also can have items such as astroscope, logic analyzer and any of the measuring equipments then there is a code checker code reviews and all that static analysis, dynamic analysis x are offered in the editing review this is simply from the object file so these are some of the embedded system modes I think the questions I have covered in this class TM method question how TM method is different than normal embedded system normal embedded system testing okay we will see you in the next class