The Experts below are selected from a list of 285 Experts worldwide ranked by ideXlab platform
Philip Koopman - One of the best experts on this subject based on the ideXlab platform.
-
Robustness Testing of A Distributed Simulation Backplane
2018Co-Authors: K. Fernsler, Philip KoopmanAbstract:Creating robust software requires not only careful specification and implementation, but also quantitative measurement. This paper describes Ballista exception handling testing of the High Level Architecture Run-Time Infrastructure (HLA RTI). The RTI is a standard distributed simulation system intended to provide completely robust exception handling, yet implementations have normalized robustness failure rates as high as 10%. Non-robust testing responses include exception handler crashes, segmentation violations, "unknown" exceptions, and task hangs. Other issues include different robustness failure modes across ports to two operating systems, and mandatory client machine rebooting after a particular RTI failure. Testing the RTI led to scalable extensions of the Ballista architecture for handling exception-based error reporting models, testing object-oriented software structures (including call-backs, pass by reference, and constructors), and operating in a state-rich, distributed system environment. These results demonstrate that robustness testing can provide useful feedback to high-quality software development processes, and can be applied to domains well beyond the previous work on testing operating systems.
-
Published In
2014Co-Authors: K. Fernsler, Philip Koopman, Issre FernslerAbstract:Creating robust software requires not only careful specification and implementation, but also quantitative measurement. This paper describes Ballista exception handling testing of the High Level Architecture Run-Time Infrastructure (HLA RTI). The RTI is a standard distributed simulation system intended to provide com-pletely robust exception handling, yet implementations have normalized robustness failure rates as high as 10%. Non-robust testing responses include exception handler crashes, segmentation violations, "unknown" exceptions, and task hangs. Other issues include differ-ent robustness failure modes across ports to two operat-ing systems, and mandatory client machine rebooting after a particular RTI failure. Testing the RTI led to scalable extensions of the Ballista architecture for han-dling exception-based error reporting models, testing object-oriented software structures (including call-backs, pass by reference, and constructors), and oper-ating in a state-rich, distributed system environment. These results demonstrate that robustness testing can provide useful feedback to high-quality software devel-opment processes, and can be applied to domains well beyond the previous work on testing operating systems. 1
-
ISSRE - Robustness testing of a distributed simulation backplane
Proceedings 10th International Symposium on Software Reliability Engineering (Cat. No.PR00443), 1999Co-Authors: K. Fernsler, Philip KoopmanAbstract:Creating robust software requires not only careful specification and implementation, but also quantitative measurement. This paper describes Ballista exception handling testing of the High Level Architecture RunTime Infrastructure (HLA RTI). The RTI is a standard distributed simulation system intended to provide completely robust exception handling, yet implementations have normalized robustness failure rates as high as 10%. Non-robust testing responses include exception handler crashes, segmentation violations, "unknown" exceptions, and task hangs. Other issues include different robustness failure modes across ports to two operating systems, and mandatory client machine rebooting after a particular RTl failure. Testing the RTI led to scalable extensions of the Ballista architecture for handling exception-based error reporting models, testing object-oriented software structures (including call-backs, pass by reference, and constructors), and operating in a state-rich, distributed system environment. These results demonstrate that robustness testing can provide useful feedback to high-quality software development processes, and can be applied to domains well beyond the previous work on testing operating systems.
John Miller - One of the best experts on this subject based on the ideXlab platform.
-
exception Handling in Workflow Systems 1
2008Co-Authors: Zongwei Luo, Amit Sheth, Krys Kochut, John MillerAbstract:In this paper, defeasible workflow is proposed as a framework to support exception handling for workflow management. By using the “justified ” ECA rules to capture more contexts in workflow modeling, defeasible workflow uses context dependent reasoning to enhance the exception handling capability of workflow management systems. In particular, this limits possible alternative exception handler candidates in dealing with exceptional situations. Furthermore, a case-based reasoning (CBR) mechanism with integrated human involvement is used to improve the exception handling capabilities. This involves collecting cases to capture experiences in handling exceptions, retrieving similar prior exception handling cases, and reusing the exception handling experiences captured in those cases in new situations
-
exception Handling in Workflow Systems
Applied Intelligence, 2000Co-Authors: Zongwei Luo, Amit Sheth, Krys Kochut, John MillerAbstract:In this paper, defeasible workflow is proposed as a framework to support exception handling for workflow management. By using the “justified” ECA rules to capture more contexts in workflow modeling, defeasible workflow uses context dependent reasoning to enhance the exception handling capability of workflow management systems. In particular, this limits possible alternative exception handler candidates in dealing with exceptional situations. Furthermore, a case-based reasoning (CBR) mechanism with integrated human involvement is used to improve the exception handling capabilities. This involves collecting cases to capture experiences in handling exceptions, retrieving similar prior exception handling cases, and reusing the exception handling experiences captured in those cases in new situations.
K. Fernsler - One of the best experts on this subject based on the ideXlab platform.
-
Robustness Testing of A Distributed Simulation Backplane
2018Co-Authors: K. Fernsler, Philip KoopmanAbstract:Creating robust software requires not only careful specification and implementation, but also quantitative measurement. This paper describes Ballista exception handling testing of the High Level Architecture Run-Time Infrastructure (HLA RTI). The RTI is a standard distributed simulation system intended to provide completely robust exception handling, yet implementations have normalized robustness failure rates as high as 10%. Non-robust testing responses include exception handler crashes, segmentation violations, "unknown" exceptions, and task hangs. Other issues include different robustness failure modes across ports to two operating systems, and mandatory client machine rebooting after a particular RTI failure. Testing the RTI led to scalable extensions of the Ballista architecture for handling exception-based error reporting models, testing object-oriented software structures (including call-backs, pass by reference, and constructors), and operating in a state-rich, distributed system environment. These results demonstrate that robustness testing can provide useful feedback to high-quality software development processes, and can be applied to domains well beyond the previous work on testing operating systems.
-
Published In
2014Co-Authors: K. Fernsler, Philip Koopman, Issre FernslerAbstract:Creating robust software requires not only careful specification and implementation, but also quantitative measurement. This paper describes Ballista exception handling testing of the High Level Architecture Run-Time Infrastructure (HLA RTI). The RTI is a standard distributed simulation system intended to provide com-pletely robust exception handling, yet implementations have normalized robustness failure rates as high as 10%. Non-robust testing responses include exception handler crashes, segmentation violations, "unknown" exceptions, and task hangs. Other issues include differ-ent robustness failure modes across ports to two operat-ing systems, and mandatory client machine rebooting after a particular RTI failure. Testing the RTI led to scalable extensions of the Ballista architecture for han-dling exception-based error reporting models, testing object-oriented software structures (including call-backs, pass by reference, and constructors), and oper-ating in a state-rich, distributed system environment. These results demonstrate that robustness testing can provide useful feedback to high-quality software devel-opment processes, and can be applied to domains well beyond the previous work on testing operating systems. 1
-
ISSRE - Robustness testing of a distributed simulation backplane
Proceedings 10th International Symposium on Software Reliability Engineering (Cat. No.PR00443), 1999Co-Authors: K. Fernsler, Philip KoopmanAbstract:Creating robust software requires not only careful specification and implementation, but also quantitative measurement. This paper describes Ballista exception handling testing of the High Level Architecture RunTime Infrastructure (HLA RTI). The RTI is a standard distributed simulation system intended to provide completely robust exception handling, yet implementations have normalized robustness failure rates as high as 10%. Non-robust testing responses include exception handler crashes, segmentation violations, "unknown" exceptions, and task hangs. Other issues include different robustness failure modes across ports to two operating systems, and mandatory client machine rebooting after a particular RTl failure. Testing the RTI led to scalable extensions of the Ballista architecture for handling exception-based error reporting models, testing object-oriented software structures (including call-backs, pass by reference, and constructors), and operating in a state-rich, distributed system environment. These results demonstrate that robustness testing can provide useful feedback to high-quality software development processes, and can be applied to domains well beyond the previous work on testing operating systems.
Joseph Yiu - One of the best experts on this subject based on the ideXlab platform.
-
exceptions and Interrupts
The Definitive Guide to the ARM Cortex-M0, 2011Co-Authors: Joseph YiuAbstract:This chapter discusses various aspects of exceptions and interrupts on Cortex-M0 processor. exceptions are events that cause changes in program flow control outside a normal code sequence. The software code that is executed when an exception occurs is called exception handler. It is found that if the exception handler is associated with an interrupt event, then it can also be called an interrupt handler, or interrupt service routine (ISR). Each exception source in the Cortex-M0 processor has a unique exception number and the exception number for NMI is 2, and the exception numbers for the on-chip peripherals and external interrupt sources are from 16 to 47. The Cortex-M0 microcontroller could support from 1 to 32 interrupts and the interrupt signals could be connected from on-chip peripherals. In the Cortex-M0 processor, each exception has a priority level that affects whether the exception will be carried out or if it will wait until later. It is observed that the Cortex-M0 processor supports three fixed highest priority levels and four programmable levels.
-
Chapter 21 – Software Porting
The Definitive Guide to the ARM Cortex-M0, 2011Co-Authors: Joseph YiuAbstract:Publisher Summary This chapter discusses software porting of software from 8-bit and 16-bit architectures and differences between various common ARM processors for microcontrollers. The ARM7TDMI has a number of operation modes, whereas the Cortex-M0 only has two modes. It is found that some of the exception models from the ARM7TDMI are combined in handler mode in the Cortex-M0 with different exception types. It is observed that despite the differences between the register banks, the programmer's model or R0 to R15 remains the same and Thumb instruction codes on the ARM7TDMI can be reused on the Cortex-M0, simplifying software porting. It is suggested that when the ARM7TDMI receives an interrupt request, the interrupt service routine starts in ARM state and assembly wrapper code is also required to support nested interrupts. It is shown that in the Cortex-M0 processor, PRIMASK and xPSR are separate registers and if the PRIMASK is set during the exception handler, it must be cleared before the exception exit. It is seen that SVC instruction support is optional in the Cortex-M1, whereas in the Cortex-M0 processor, SVC instruction is always available.
-
Using SVC, PendSV, and Keil RTX Kernel
The Definitive Guide to the ARM Cortex-M0, 2011Co-Authors: Joseph YiuAbstract:This chapter discusses various aspects of the Keil RTX Kernel, which is included in the Keil MDK, including the evaluation version. SuperVisor Call (SVC) is commonly used in an OS environment for application tasks to access to system services provided by the OS. The SVC involves the processes which include setting up of optional input parameters to pass to the SVC handler in registers based on programming practices outlined by AAPCS and execution of the SVC instruction. It is found that if the SVC exception handler needs to return a value back to the application task that made the SVC call, it needs to put the return value back onto the stack frame, usually where the stacked R0 is located. It is observed that the second part of the SVC handler used the extracted stack frame starting address as the input parameter and used it as a pointer to an integer array to access the stacked register values. It is shown that unlike the SVC, the PendSV exception is triggered by writing to the Interrupt Control State Register.
-
Overview of the Cortex-M3
The Definitive Guide to the ARM Cortex-M3 TI, 2010Co-Authors: Joseph YiuAbstract:This chapter provides an overview of the Cortex-M3. The Cortex-M3 is a 32-bit microprocessor. It has a 32-bit data path, a 32-bit register bank, and 32-bit memory interfaces. The processor has a Harvard architecture, which means it has a separate instruction bus and data bus. This allows instructions and data accesses to take place at the same time, and as a result of this the processor performance increases because data accesses do not affect the instruction pipeline. This feature results in multiple bus interfaces on the Cortex-M3, each with optimized usage and the ability to be used simultaneously. The Cortex-M3 processor includes a number of fixed internal debugging components. These components provide debugging operation supports and features such as breakpoints and watchpoints. In addition, optional components provide debugging features such as instruction trace and various types of debugging interfaces. The Cortex-M3 processor has two modes and two privilege levels. The operation modes (thread mode and handler mode) determine whether the processor is running a normal program or running an exception handler like an interrupt handler or system exception handler. The privilege levels (privileged level and user level) provide a mechanism for safeguarding memory accesses to critical regions as well as providing a basic security model. Additionally, the Cortex-M3 processor includes a number of debugging features such as program execution controls, including halting and stepping, instruction breakpoints, data watchpoints, registers and memory accesses, profiling, and traces.
-
CHAPTER 9 – Interrupt Behavior
The Definitive Guide to the ARM Cortex-M3 TI, 2010Co-Authors: Joseph YiuAbstract:Publisher Summary This chapter discusses the process of Interrupt/exception Sequences, which include stacking, vector fetch by the instruction bus, and update of the stack pointer, link register, and program counter. It discusses nested interrupt support, which is built into the Cortex-M3 processor core and the Nested Vectored Interrupt Controller. Interrupt latency, which refers to the delay from the start of the interrupt request to the start of interrupt handler execution, is explained. The Cortex-M3 uses a number of methods to improve interrupt latency, including tail chaining and late arrival exception handling. The chapter explores the special value called EXC_RETURN, which, when loaded into the PC at the end of the exception handler execution, will cause the processor to perform an exception return sequence. Various faults can be caused by exception handling. If a bus fault takes place during stacking or unstacking, the respective sequence will be terminated and the bus fault exception will be triggered or pended. On the other hand, if a bus fault or memory management fault takes place during a vector fetch, the hard fault handler will be executed. If the EXC_RETURN number is invalid or does not match the state of the processor, it will trigger the usage fault.
Zongwei Luo - One of the best experts on this subject based on the ideXlab platform.
-
exception Handling in Workflow Systems 1
2008Co-Authors: Zongwei Luo, Amit Sheth, Krys Kochut, John MillerAbstract:In this paper, defeasible workflow is proposed as a framework to support exception handling for workflow management. By using the “justified ” ECA rules to capture more contexts in workflow modeling, defeasible workflow uses context dependent reasoning to enhance the exception handling capability of workflow management systems. In particular, this limits possible alternative exception handler candidates in dealing with exceptional situations. Furthermore, a case-based reasoning (CBR) mechanism with integrated human involvement is used to improve the exception handling capabilities. This involves collecting cases to capture experiences in handling exceptions, retrieving similar prior exception handling cases, and reusing the exception handling experiences captured in those cases in new situations
-
exception Handling in Workflow Systems
Applied Intelligence, 2000Co-Authors: Zongwei Luo, Amit Sheth, Krys Kochut, John MillerAbstract:In this paper, defeasible workflow is proposed as a framework to support exception handling for workflow management. By using the “justified” ECA rules to capture more contexts in workflow modeling, defeasible workflow uses context dependent reasoning to enhance the exception handling capability of workflow management systems. In particular, this limits possible alternative exception handler candidates in dealing with exceptional situations. Furthermore, a case-based reasoning (CBR) mechanism with integrated human involvement is used to improve the exception handling capabilities. This involves collecting cases to capture experiences in handling exceptions, retrieving similar prior exception handling cases, and reusing the exception handling experiences captured in those cases in new situations.
