Scientific Library of Tomsk State University

   E-catalog        

Normal view MARC view

Stuck-at-faults tester as a web-service N. A. Shalyapina, A. A. Zaytsev, S. V. Batratskiy, M. L. Gromov

Contributor(s): Zaytsev, A. A | Batratskiy, S. V | Gromov, Maxim L | Shalyapina, N. AMaterial type: ArticleArticleContent type: Текст Media type: электронный Other title: Тесты на константные неисправности как веб-сервис [Parallel title]Subject(s): константные неисправности | комбинационные схемы | проверяющие тесты | Web-сервисыGenre/Form: статьи в журналах Online resources: Click here to access online In: Труды Института системного программирования РАН Т. 30, вып. 1. С. 41-54Abstract: In this paper, we tell about a web-service we would like to develop. There are two goals we aim at, when developing this service. The first one is to give researchers a platform, where they could conduct preliminary experiments with different methods of test generation for digital circuits, in order to check different ideas. The second one is an opportunity to share implementations of new developed methods “on-the-fly”. The web-service development procedure was splitted into three stages: the architecture design, a light version implementation and the actual implementation. This paper tells about first two stages. There are two types of web-service architectures – with monolithic kernel and with microkernel – and our architecture has the properties of both types. The intention was to have monolithic kernel, since the desired functionality is not that hard to implement. However, the property of being extensible by implementations of new methods implies that part of the functions (namely the methods implementations) should be designed as separate sub-services. The light version implementation was done for the only method: method of fault domain enumeration for the stuck-at-faults fault model. It proved that the designed architecture is viable. However, some issues with the architecture were discovered. A mechanism of on-the-fly deployment of a new method is unclear, since it is not obvious, how to satisfy possible dependences of the implementation. Also, the architecture does not follow the classical web-service design: the service has states, that should not be, if a service is intended to be the classical one. The resolution of these issues is left for the future.
Tags from this library: No tags from this library for this title. Log in to add tags.
No physical items for this record

Библиогр.: 11 назв.

In this paper, we tell about a web-service we would like to develop. There are two goals we aim at, when developing this service. The first one is to give researchers a platform, where they could conduct preliminary experiments with different methods of test generation for digital circuits, in order to check different ideas. The second one is an opportunity to share implementations of new developed methods “on-the-fly”. The web-service development procedure was splitted into three stages: the architecture design, a light version implementation and the actual implementation. This paper tells about first two stages. There are two types of web-service architectures – with monolithic kernel and with microkernel – and our architecture has the properties of both types. The intention was to have monolithic kernel, since the desired functionality is not that hard to implement. However, the property of being extensible by implementations of new methods implies that part of the functions (namely the methods implementations) should be designed as separate sub-services. The light version implementation was done for the only method: method of fault domain enumeration for the stuck-at-faults fault model. It proved that the designed architecture is viable. However, some issues with the architecture were discovered. A mechanism of on-the-fly deployment of a new method is unclear, since it is not obvious, how to satisfy possible dependences of the implementation. Also, the architecture does not follow the classical web-service design: the service has states, that should not be, if a service is intended to be the classical one. The resolution of these issues is left for the future.

There are no comments on this title.

to post a comment.
Share