System Integration Testing and Debugging Methodology Prof Sachin
System Integration , Testing and Debugging Methodology Prof. Sachin B. Charbhe Electronics Department Rizvi College of Engg. , Bandra(W) RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
System Integration �System Integration is the process of integrating all the physical and virtual components of an organisation’s system. �The physical components consist of the various machine systems, computer hardware, inventory, etc. �The virtual components consists of data stored in databases, software and applications. �The process of integrating all these components, so that act like a single system, is the main focus of system integration. RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Integration of control system �Integration of Hardware Integration of controller (DCS, PLC, ESD) and I/O Implementation of control system network Production of power distribution system Production of marshalling panel �Integration of software Program & configuration of loop Program & configuration of logic Interface of third party system RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Industrial network system �Integration of Hardware Industrial control network system Industrial wireless network system �Integration of software NMS(Network Management Software) RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Operator console & workstation �Integration of hardware Industrial workstation Industrial rigid console �Integration of software Operator workstation software of DCS, PLC, ESD Historian Report station RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Embedded Product Design Life-Cycle (EDLC) �An Embedded development life cycle is a complete sequence of activities from a requirement capture to product delivery. RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
This involves Several steps as follows. � Capture Product Requirement Specifications Document � Derive Software/Hardware Requirements documents using PRD � Project planning and tracking: Resource planning, Budget planning, Risk plan and mitigation, Travel Plan, SCM plan, Test Resource identification and planning etc � Design: Involves Low level and High level Designs RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
� Implementations- Coding, debugging, fixing issues, debugging hardware, Writing test code to test hardware, DIT � Testing -System Integration Testing Cycles (Generally 3 cycles) � Beta Release for field trail � Final Release and Addressing field issues � If you are developing both hardware and software, then the development happens in parallel RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Need for EDLC � EDLC is essential for understanding the scope and complexity of the work involved in embedded systems development � It can be used in any developing any embedded product � EDLC defines the interaction and activities among various groups of a product development phase. �Example: -project management, system design RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
DIFFERENT PHASES OF EDLC RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
�Conceptualization Defines the scope of concept, performs cost benefit analysis and feasibility study and prepare project management and risk management plans. �Analysis and Documentations This activity consolidates the business needs of the product under development. �Defining Test Plan and Procedures The various type of testing performed in a product development are RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
�Unit testing – Testing Individual modules �Integration testing – Testing a group of modules for required functionality �System testing- Testing functional aspects or functional requirements of the product after integration �User acceptance testing- Testing the product to meet the end user requirements. �Design �The design phase identifies application environment and creates an overall architecture for the product. RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Hardware/software co-design �Hardware/software co-design investigates the concurrent design of hardware and software components of complex electronic systems. �It tries to exploit the synergy of hardware and software with the goal to optimize and/or satisfy design constraints �Such as cost, performance, and power of the final product. At the same time, it targets to reduce the time-to-market frame considerably. RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
� Co-ordination: � Concurrency � Correctness � Complexity RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Testing & Debugging �Testing means verifying correct behavior. Testing can be done at all stages of module development: � requirements analysis �interface design �algorithm design � implementation � integration with other modules. �Implementation testing is not restricted to execution testing. An implementation can also be tested using correctness proofs, code tracing, and peer reviews RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
�Debugging is a cyclic activity involving execution testing and code correction. �The testing that is done during debugging has a different aim than final module testing. �Final module testing aims to demonstrate correctness, whereas testing during debugging is primarily aimed at locating errors. �This difference has a significant effect on the choice of testing strategies. RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Boundary-scan/JTAG interface concepts �Boundary scan is a method for testing interconnects (wire lines) on printed circuit boards or sub-blocks inside an integrated circuit. �Boundary scan is also widely used as a debugging method to watch integrated circuit pin states, measure voltage, or analyze subblocks inside an integrated circuit. RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
�The Joint Test Action Group (JTAG) developed a specification for boundary scan testing that was standardized in 1990 as the IEEE Std. 1149. 1 -1990. �In 1994, a supplement that contains a description of the Boundary Scan Description Language(BSDL) was added which describes the boundary-scan logic content of IEEE Std 1149. 1 compliant devices. � Since then, this standard has been adopted by electronic device companies all over the world. Boundary scan is now mostly synonymous with JTAG RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
What is Boundary Scan? �Boundary scan is a methodology allowing complete controllability and observability of the boundary pins of a JTAG compatible device via software control. This capability enables in-circuit testing without the need of bed-of-nail in-circuit test equipment. � During standard operations, boundary cells are inactive and allow data to be propagated through the device normally. During test modes, all input signals are captured for analysis and all output signals are preset to test down-string devices. The operation of these scan cells is controlled through the Test Access Port (TAP) Controller RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
�The TAP controller is a state machine (16 possible states) controlling operations associated with boundary scan cells. The basic operation is controlled through four pins: Test Clock (TCK), Test Mode Select (TMS), Test Data In (TDI), and Test Data Out (TDO). �The TCK and TMS pins direct signals between TAP controller states. The TDI and TDO pins receive the data input and output signals for the scan chain. Optionally, a fifth pin, TRST, can be implemented as an asynchronous reset signal to the TAP controller. RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
JTAG TAP Interface Signals RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Black Box Testing / White Box Testing �Black Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is NOT known to the tester �White Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
White-box Testing Four types of white-box testing �Statement Testing �Loop Testing �Path Testing �Branch Testing RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
�Statement Testing (Algebraic Testing): Test single statements �Loop Testing: �Cause execution of the loop to be skipped completely. (Exception: Repeat loops) �Loop to be executed exactly once �Loop to be executed more than once �Path testing: �Make sure all paths in the program are executed �Branch Testing (Conditional Testing): Make sure that each possible outcome from a condition is tested at least once RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Constructing the Logic Flow Diagram RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Comparison of White & Black-box Testing � White-box Testing: � Potentially infinite number of paths have to be tested � White-box testing often tests what is done, instead of what should be done � Cannot detect missing use cases � Black-box Testing: � Potential combinatorical explosion of test cases (valid & invalid data) � Often not clear whether the selected test cases uncover a particular error � Does not discover extraneous use cases ("features") � Both types of testing are needed � White-box testing and black box testing are the extreme ends of a testing continuum. � Any choice of test case lies in between and depends on the following: � Number of possible logical paths � Nature of input data � Amount of computation � Complexity of algorithms and data structures RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Black Box Testing White Box Testing �It is a way of software testing in which the internal structure or the program or the code is hidden and nothing is known about it. �It is mostly done by software testers. �No knowledge of implementation is needed. �It can be referred as outer or external software testing. �It is functional test of the software. �It is a way of testing the software in which the tester has knowledge about the internal structure r the code or the program of the software. �It is mostly done by software developers. �Knowledge of implementation is required. �It is the inner or the internal software testing. �It is structural test of the software. RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
�This testing can be initiated on the basis of requirement specifications document. �No knowledge of programming is required �It is the behavior testing of the software. �It is applicable to the higher levels of testing of software. �It is also called closed testing. �Can be done by trial and error ways and methods. �This type of testing of software is started after detail design document. �It is mandatory to have knowledge of programming. �It is the logic testing of the software. �It is generally applicable to the lower levels of software testing. �It is also called as clear box testing. �Data domains along with inner or internal boundaries can be better tested. RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
Types of Black Box �A. Functional Testing �B. Non-functional testing Tyeps of White Box Testing �A. Path Testinge �B. Loop Testing �C. Condition testing �C. Regression Testing RCOE | PROF. SACHIN CHARBHE | ESD & RTOS
- Slides: 48