A Domain Specific Language Oriented to
Fault Detection, Isolation and Recovery
Maria Carmela Vitelli Massimo Tipaldi
R&D Department SW Department
Intelligentia srl OHB System AG
I-82100 Benevento, Italy D-28359 Bremen, Germany
Email: mcarmela.vitelli@intelligentia.it Email: massimo.tipaldi@ohb-system.de
Abstract—Reliability of complex systems requires to take into
account possible failures and strategies to detect and recover
from system faults. This leads designers to consider models and
algorithms capable of simulating and verifying fault detection,
isolation and recovery (FDIR) strategies in different scenarios,
characterized by uncertainty and partial information. Different
solutions have been proposed. In this paper we present Trouble,
a domain specific language aimed at describing and simulating
troubleshooting algorithm. Different examples highlight advan-
tages of such an approach.
Index Terms—FDIR; reliable systems; domain-specific lan-
guages; Bayesian troubleshooting.
I. I NTRODUCTION
Reliable systems count on mechanisms to detect faults and
solve failures. This issue is particularly relevant in various
industrial contexts and applications such as (aero)space, indus-
trial plants and machinery, automotive, robotics, etc. A large
research effort has been paid over the past decade to both the
theoretical and the application side in order to propose and test
different solutions. In particular, the space industry is focusing
on how to design e.g. satellites and planetary spacecrafts
equipped with Fault Detection, Isolation and Recovery (FDIR)
capabilities and high autonomy level [1], [2].
The approach hereafter proposed is domain-specific, there-
fore focused on the definition of languages used to describe
the system structure, its behavior in the presence of faults and
procedures to recover from failures. This approach is different
from others which rely on white or black-box models (e.g.,
see [3], [4], [5], [6], [7], [8]), are generally application-specific
and require to be linked as libraries within a program written
to control the system instead of troubleshooting it. Contrary
to this, Domain Specific Languages (DSL) offer the chance
of focusing on the FDIR issues from a system standpoint
by dealing with concepts and aspects familiar to whom is in
charge of designing the system fault-tolerance capabilities.
In this paper we present Troubles, a domain specific lan-
guage, conceived to model and design algorithms for system
troubleshooting. The remainder of this paper is organized as
follows: section 2 provides an overview of other languages
and solutions for system health management and simulation;
section 3 is aimed at describing Troubles features and syn-
tax; section 4 provides an example of application; section 5
outlines conclusions and future directions.
978-1-4799-3400-3/13/$31.00 ©2013 IEEE 343
Luigi Troiano
Dept. of Engineering
University of Sannio
I-82100 Benevento, Italy
Email: troiano@unisannio.it
II. R ELATED WORKS
Different languages and solutions related to FDIR and
Health Management Systems have been proposed over the past
decades. In this section we report some examples from the
literature.
Hoara and Tixeuil [9] presented FAIL (Fault Injection
Language) and FCI (Fail Cluster Implementation) for software
fault injection in distributed applications. FAIL is a language
that permits to elaborate complex fault scenarios without
writing low level code. FCI consists of a compiler, a runtime
library and a middleware platform for software fault injection
in distributed applications. It is able to interface with numerous
programming languages without requiring the modification
of their source code. The authors studied crash faults in
asynchronous distributed applications and provided a scheme
for distributed software fault injection. Software approaches
have different advantages since they are easier to set up, can
be reproduced and do not risk damaging the hardware.
Misera et al. [10] developed a hierarchical fault simulation
enviroment called FIT based on VHDL and C++. Its main
feature is the propagation of fault effects over functional
blocks that are not available in form of gate level models. C++
cannot handle typical properties of hardware like concurrency,
therefore SystemC is used. In this paper the authors presented
a new approach where the SystemC simulation task is incor-
porates as ”thread” process into the FIT simulation process. In
this way they managed to combine an effective modeling of
fault conditions with reasonable performance of the simulator.
VHDL is also treated in [11], where Friedrich et al. de-
scribed an approach to use model-based diagnosis for fault
detection and localization in VHDL programs. The initial
specification represents the functional requirements for the
hardware to be designed. Then there is a detailed design on the
RT level, that is converted into a gate-level after some tests.
The simulations produce waveform traces that are compared
to other traces previously generated. If there is a discrepancy
then there is a fault in the design. Model-based system is rep-
resented through system description and observations. System
description is derived from VHDL program and observations
are based on traces produced by simulation or user indication
of incorrect signal values entered.
 In [12] we can find another example of description language
for circuit failures and faults. This language is able to support
the structural configuration design of circuits with the view
to verifying statically when unexpected failures arise within
circuits. The ”circuits as predicate” paradigm is adopted,
where the circuit behavior is interpreted via predicates.
Funabashi et al. [13] introduced a time domain model of a
fault locator using MODELS, a language in the APT version of
EMTP. The fault locator model has an input analog filter, sam-
pling hold and digital filters, magnitude and phase calculation,
fault locating algorithm and statistical output procedure. It can
model various fault types using different simulation cases.
LISA [14] is a machine description language. LISA and
its generic machine model are able to produce processor
models covering HW/SW co-design needs and co-simulation
enviroment. This language was developed to cover the gap
between coarse ISA models (used in compilers and instruction-
set simulators) and detailed models (used for hardware design).
The purpose of this language was to define a single generic
machine model and a single description language to cover a
whole class of processor architectures.
In fault diagnosis for discrete event system, because of an
insufficient number of sensors in the system, it is common runn
that a diagnosis result may contain several fault candidates. Su
and Wonham [15] explain how to construct a probability space
over a regular language and how to perform a probabilistic
reasoning to reduce diagnostic ambiguity. There are a lot of
probabilistic approaches to handle fault diagnosis, some of
them are based on bayesian network and on hidden markov
models. The authors used a standard method from the theory
of markov process to define a probability space over a regular
language. They defined a simplified connection between a
local language model and the associated probability model to
perform a faster on-line probabilistic reasoning.
Troiano and De Pasquale [16] proposed a methodology to
decompose a complex problem in more treatable parts and
an application of Bayesian approach to industrial case. They
described a Bayesian network methodology to support and
drive decision in troubleshooting.
III. L ANGUAGE SPECIFICATION
A. General charascteristics
Troubles is a domain-specific language (DSL) aimed at
modeling and solving troubleshooting problems under uncer-
tainty. Troubles is able to describe a troubleshooting problem
in terms of faults, observations and repairing actions. Trou-
bleshooting procedural logic can be specified to define the
solver algorithm. In order to promote model reuse, system/sub-
system relationships are prescribed as well.
Faults. Also named issues, they represent a deviation from
the normal operation of the system. To define a system fault it
is necessary to observe an anomaly or a failure effect. Faults
are organized hierarchically: elementary faults represents the
leaves and their aggregation define more generic issues. For
each and every issue, the failure rate has to be defined.
344 2013 International Conference of Soft Computing and Pattern Recognition (SoCPaR)
Observations. An observation is used to identify the current
status of the system. It is characterized by a series of states
that define the possible options to select exclusively. An
observation has no cost associated and should be able to select
or discard a number of issues of the system.
Repairing Actions. If executed, an action set may restore
the system into nominal operation. An action has an associated
cost and can be linked to a subset of all the issues. It is
necessary to define a repair probability.
Solvers. Solver’s role is the fault identification and recovery.
It is based on bayesian models and represents the resolution
algorithm. Solver should support the operator in detecting
faults in the real system. It is characterized by an actions set
to be performed on the affected system in order to restore its
normal operating status and optimizes the restore procedure
taking into account the efficiency of the operations being
performed.
Model Reuse. Thanks to Troubles, it’s possible to reuse
models previously defined. It’s possible to reuse both the
whole model and/or some of its constituents.
Abstraction. Another important characteristic of Troubles
is the abstraction given by the inclusion rule: one or more
systems can be included in the current system and can be
overwritten.
Language. Troubles is a highly declarative language since
the descriptive logic is made up of a set of definitions (decla-
rations). We have different types of construct featured by its
own keyword and properties but the same construct structure.
This makes Troubles orthogonal. The base declaration is
interchangeable, therefore it can be used for various constructs.
Troubles language is not strongly typed and has an implicit
typesation, therefore the type is given by the right expression
at execution time. Troubles is also a structured language. As
consequence, there is a particular form to be complied with:
firstly, there is a descriptive logic with a definition of different
elements, and secondly a solver logic with a procedure for the
solver algorithm definition.
Troubles is an inherently domain-specific language, there-
fore it has certain some advantages over linked libraries, i.e.
expressiveness, compactness in terms of declarations, code line
number and domain-level sematic control at translation time
rather than at execution time.
B. Syntax
Troubles is based on a free-context grammar for the lan-
guage L, defined as the quadruple G = (N T, T, R, S), where
• NT is the finite set of non-terminal symbols, which
specify either a class or a syntactic category
• T is the tree of the terminal symbols for the language L
• S is a non-terminal symbol (S ∈ N T ) called start symbol
• R is the production rules set, used to describe all non-
terminal symbols
Terminal symbols are keywords or symbols which are
featured by a particular meaning. In our grammar, terminal
symbols define particular constructs (e.g. system, failures,
 Fig. 1. Production rule: script

actions, observations), structural constructs (e.g. for, repeat-

until), identifiers, numeric constants and operators.
Our start symbol is script (Fig. 1). It is a production rule
that represents the input scheme to follow. This production
rule is characterized by other non-terminal symbols: include, (a) systemDef
systemDef, labelsDef, issueDef, observationDef, actionDef
and procedure. This is a result of its highly declarative and
structural property. As depicted in Fig. 1, the input file is a
sequence of definitions that have a precise order and structure.
include (Fig. 2) verifies the modularity property: it allows
to link other systems/sub-systems (or part of them) previously (b) issueDef
defined in our current model.

(c) actionDef
Fig. 2. Non-terminal symbol: include

qualifiedName is a sequence of identifiers interspaced by

points. It is used to specify if the whole system or only a part
of it has to be included.
By means of labelsDef (Fig. 3) we define not strongly
typed variables that can be used in the input file. They can
are be strings and numerics such as float literal, integer literal
and percentage literal. For each type, different operators are
available: qualification operator, concatenation operator and
algebraic, logical and relational operators.
Fig. 3. Non-terminal symbol: label
systemDef is used to describe the system and allows the
reuse of other systems/sub-systems previously defined, which
can be totally or in part reused and overwritten.
In the context of FDIR-domain definitions, the following
non-terminal symbols have been introduced (Fig. 4):
• issueDef defines faults with their probability occurrence
• observationDef production rule defines observations that
the logic resolver has to process
• actionDef is the production rule that defines the repairing
action that may solve the issue
It is worth mentioning that systemDef, issueDef, obser-
vationDef and actionDef are all constructs based on the
(d) observationDef
Fig. 4. Non-terminal symbol: FDIR-domain definitions
production rule called definition (Fig. 6). This rule allows the
orthogonal property. It is a complex rule which requires the
presence of optional elements as well as elements that can be
repeated several times. It is made up of the following elements:
• identifier is optional, therefore it is not mandatory to give
a name to a definition construct
• the number and value of parameters depends on the
constructs we are about to define (e.g. it can be a string
in systemDef or a numeric value representing the cost of
the action in actionDef)
• block, an optional element, that can enclose inside the
braces one or more definition that can be preceded or
not by a marker or a particular symbol that allows a tree
definition
• colon is used in subtrees definition
• atClause (Fig. 5) is optional and allows the creation of
decorated tree structure and the atClause rule creates links
between its nodes.
The production rule procedure (Fig. 7) is used to define the
solver algorithm. body is a set of statements that allows the
troubleshooting execution. Statements are Java/C++-like and

2013 International Conference of Soft Computing and Pattern Recognition (SoCPaR) 345
 Fig. 6. Production rule: definition

attention to the control density, that is, relationship between

model consistency calls and overall consistency calls: the re-
sulting value represents the percentage of control that changes
from run time to compile time thanks to this new language.
Fig. 5. Production rule: atClause Three case studies have been taken into account, i.e. Internet
Connection System, Satellite System and Computer System.
Computer model is based on the identification and resolu-
can be assignment, expression, callExpression, ifStatement, tion of faults that may occur on a computer. A computer is
whileStatement, repeatStatement and forStatement. made up of several components, consequently parts of other
systems are identified, e.g. the Monitor model, hard disk model
or power supply model.
Hereafter, some excerpts from input files in Troubles are
listed. The following code shows an example of inclusion:
(a) procedure
use PowerSupply;
use Monitor;
use HD;
use Motherboard;
The system ”My pc” reuses systems from the imported
models:
system ’My pc’ : {
(b) body PowerSupply [PowerSupply];
Monitor [Monitor];
Fig. 7. Production rule: procedure Motherboard [Motherboard];
HardDisk [HD];
};
IV. A N ILLUSTRATIVE EXAMPLE In the following, we define some system issues. Each issue
Troubles is able to instantiate Bayesian models. In this has an associated probability to occur. In this case ”power
section, Dygnose [16] is considered with a view to pointing issues” has 5 sub-issues: some of them are imported from
out the benefits of the proposed approach. Dygnose is a soft- reused systems, e.g. ”cable issues” is linked to PowerSupply
ware tool with inborn problems identification and resolution system.
capabilities. In particular, it is able to lead the operator towards failures ComputerIssues : {
system failure identification and recovery under a remarkable .....
uncertainty level. Dygnose is characterized by two phases: ’power issues’ [45.45%] : {
- blackout [21.23%];
system modeling and system execution. As for the first phase, - ’cable issues’ [50.82%] :
all the necessary data to give a description to the addressed @ PowerSupply.’cable is damaged or not connected’;
system are collected. - ’monitor issues’ [12.53%] :
@ Monitor.’generic issue’;
The troubleshooting model creation follows same steps: - ’motherboard issues’ [4.23%] :
problem identification, identification of their causes, identi- @ Motherboard.’generic issue’;
- ’power supply issues’ [11.19%] :
fication of all the actions that may resolve them, identification @ PowerSupply.’generic issue’;
of all the observations that will give useful information about };
the causes of the problem. .....
};
Troubles input files can be integrated with Dygnose since
such files can be preprocessed/translated into Java and then In the following section, the observation definitions are
executed within the Dyagnose framework. We have analyze the shown. For each observation, we set the probability linked
inputs provided by the Troubles code and the corresponding to the specific state and issue.
translation in Java and Dygnose API. In particular, the source
observations Observations : {
lines of code (SLOC) for both the files (input and output) ......
have been assessed. As for .java files, we would like to pay - ’how many beeps are emitted?’ : {

346 2013 International Conference of Soft Computing and Pattern Recognition (SoCPaR)
’1’;
’2’; TSRepository repository = TSWorkspace.getInstance().
’no beep’; getRepositoryForLocation(
’continuos beep’; TSWorkspace.SINGLE_FILE_SYSTEM_BASED, repositoryPath);
};
TSWorkspace.getInstance().loadRepository(repository);
@’power issues’ [-0.25, -0.21, 0.49, -0.21],
@blackout [-1.00, -1.00, 0.70, -1.00], TSPackage packSingleSystems =
@’cable issues’ [0.00, 0.00, 0.50, 0.00], repository.getPackage("computerSingleSystem");
..... TSPackage packSistemaComputer =
@’hardware conflict’ [0.00, 0.00, 0.70, 0.00], repository.createPackage("sistemaComputer");
@’generic device is damaged’ [-0.60, 0.00, 0.70, 0.00], TSSystem sysComputer =
@’generic post issue’ [0.00, 0.50, 0.00, 0.00]; repository.createSystem(packSistemaComputer);

TSSystem sysHardDisk = packSingleSystems.getSystem("HardDisk");

..... .....
}; TSSystem sysPowerSupply =
packSingleSystems.getSystem("PowerSupply");
Likewise, for each and every action there is a probability
TSPart powerSupply = sysPowerSupply.getPart("PoweSypply");
associated with some issues, which states the likelihood of the .....
action in solving the i-issue. TSPart motherboard = sysPowerSupply.getPart("Motherboard");

actions Actions : { sysComputer.setName("My pc");

..... sysComputer.addPart(powerSupply);
- ’update bios’ [25.00] : sysComputer.addPart(monitor);
@’power issues’ [0.00], sysComputer.addPart(hardDisk);
sysComputer.addPart(motherboard);
@’post issues’ [0.11],
@’keyboard failure’ [0.00], TSIssue rootIssue = sysComputer.getRootIssue();
... TSIssue powerIssue = sysComputer.createIssue(rootIssue);
@’hardware conflict’ [0.50], powerIssue.setName("power issues");
@’generic device is damaged’ [0.00], powerIssue.setFrequency(0.45);
@’generic post issue’ [0.40];
TSIssue blackout = sysComputer.createIssue(powerIssue);
..... blackout.setName("blackout");
blackout.setFrequency(0.21);
};
TSIssueLink cableIssues =
After defining the system with the associated issues, ob- sysComputer.createIssueLink(powerIssue);
servations and actions, the resolving procedure has to be cableIssues.setName("cable issues");
cableIssues.setFrequency(0.50);
implemented. A procedure is a set of instructions with the
purpose of performing troubleshooting and solving/isolating TSIssueLink monitorIssues =
sysComputer.createIssueLink(powerIssue);
failures. monitorIssues.setName("monitor issues");
monitorIssues.setFrequency(0.12);
algorithm Algorithm : {
.list = addAll(Actions); TSIssueLink motherboardIssues =
.list = addAll(Observations); sysComputer.createIssueLink(powerIssue);
motherboardIssues.setName("motherboard issues");
.i = .list.size(); motherboardIssues.setFrequency(0.04);

TSIssueLink powerSupplyIssues =
while(.list.next) { sysComputer.createIssueLink(powerIssue);
.pi = .list.prob; powerSupplyIssues.setName("power supply issues");
.c = .list.cost; powerSupplyIssues.setFrequency(0.11);
.list.eff = .pi / .c; .....
}
TSObservation numBeep = sysComputer.createObservation();
.orderedList = .list.sortedby( .eff ); numBeep.setName("how many beeps are emetted?");
numBeep.createState("1","description");
.solved = false;
numBeep.createState("2","description");
.size = .orderedList.size(); numBeep.createState("no beep","description");
numBeep.createState("continuos beep","description");
while(.orderedList.next || .solved == true) {
.execution = .oderedList.execute(); numBeep.setBipolarObservingProbability(powerIssue,
if(.execution == true) { new double[]{-0.25,-0.21,0.49,-0.21});
.solved = true; numBeep.setBipolarObservingProbability(blackout,
.str > new double[]{-1.00,-1.00,0.70,-1.00});
numBeep.setBipolarObservingProbability(cableIssues,
java.lang.String("Troubleshooting finished.");
new double[]{0.00,0.00,0.50,0.00});
} .....
} numBeep.setBipolarObservingProbability(hardwareConflict,
} new double[]{0.00,0.00,0.70,0.00});
numBeep.setBipolarObservingProbability(genericDeviceDamaged,
In the following, the translated code in Java and Dygnose new double[]{-0.60,0.00,0.70,0.00});
numBeep.setBipolarObservingProbability(genericPostIssue,
API is reported. new double[]{0.00,0.50,0.00,0.00});
TSWorkspace.getInstance().loadWorkspace();
.....
String repositoryPath = "C:\\Documents and Settings\\
TSRepairingAction updateBios =
Administrator\\Documenti\\Troubleworkspace\\computer.xml";

2013 International Conference of Soft Computing and Pattern Recognition (SoCPaR) 347
 TABLE I represent the reasoning algorithms. Model reuse and ab-
T ROUBLES VS JAVA T RANSLATION . straction are features which make Troubles scripts to scale
SLOC Troubles SLOC Java Control density problem complexity. In addition, the language is highly
Internet Connec- declarative, implicitly typed, orthogonal and structured. The
tion System 208 351 0.93
Satellite System 231 457 0.94
current version of the language is specifically designed to
Computer work with troubleshooting problems under uncertainty. The
System 332 558 0.94 example demonstrates how the same problem can be described
more concisely than using hosted libraries. Moreover, some
(domain-specific) controls which should be kept at runtime in
sysComputer.createRepairingAction(); the case of software libraries can be moved at compile time in
updateBios.setName("update bios"); the case of Troubles scripts. This improves solver verification
updateBios.setCost(25.0);
updateBios.setRepairingProbability(powerIssue,0.00); and performances. The version of Troubles presented in this
updateBios.setRepairingProbability(postIssues,0.11); paper is only preliminary. We aim at developing more in depth
updateBios.setRepairingProbability(keyboardFailure,0.00);
..... the language constructs and providing simulation capabilities
updateBios.setRepairingProbability(hardwareConflict,0.50); that are lacking at the moment.
updateBios.setRepairingProbability(genericDeviceDamaged,
0.00); R EFERENCES
updateBios.setRepairingProbability(genericPostIssue,0.40);
[1] A. Zolghadri, “Advanced model-based FDIR techniques for aerospace
..... systems: Today challenges and opportnunities,” Progress in Aerospace
Sciences, vol. 53, pp. 18–29, 2012.
//we create a session
TSSession session = new TSSession(sysComputer,
[2] X. Olive, “FDI(R) for satellites: how to deal with high availability
"nome dell’operatore", "nome del cliente"); and robustness in the space domain?” International Journal of Applied
TSReasoner reasoner = TSReasonerBuilder.createReasoner( Mathematics and Computer Science, vol. 22, no. 1, pp. 99–107, 2012.
TSReasonerBuilder.HUGIN_REASONER); [3] S. Ierace, P. Marinaro, P. Tatavitto, and L. Troiano, “Profiling the power
usage of industrial machinery by ann,” in Soft Computing and Pattern
//we start the session Recognition (SoCPaR), 2010 International Conference of, 2010, pp.
session.startSession(reasoner); 413–418.
[4] S. Ierace, R. Pinto, L. Troiano, and S. Cavalieri, “Neural network as an
TSSecondaryList<TSStep> suggestions =
session.getSuggestions();
efficient diagnostics tool: A case study in a textile company,” vol. 1, no.
TSSecondaryList<TSEvidence<TSObservation>> PART 1, 2010, pp. 122–127.
observations = session.getObservations(); [5] L. Troiano, G. Scibelli, and C. Birtolo, “A fast algorithm for mining rare
itemsets,” in ISDA. IEEE Computer Society, 2009, pp. 1149–1155.
TSSecondaryList<TSOperation> list = new TSSecondaryList [6] L. Troiano, M. Tipaldi, A. Di Cerbo, M. Hoping, D. De Pasquale, and
<TSOperation>(null, TSDefaultSorters.EXPECTED_COST_SORTER); B. Bruenjcs, “Satellite fdir practices using timed failure propagation
list.linkTo(suggestions); graphs,” vol. 11, 2012, pp. 8524–8531.
list.linkTo(observations); [7] L. Troiano and G. Scibelli, “A time-efficient breadth-first level-wise
list.sortElements();
lattice-traversal algorithm to discover rare itemsets,” Data Mining
and Knowledge Discovery, pp. 1–35, 2013. [Online]. Available:
boolean solved = false; http://dx.doi.org/10.1007/s10618-013-0304-3
[8] S. Rampone, V. Pierro, L. Troiano, and I. Pinto, “Neural network
while (list.size() > 0 || solved) { aided glitch-burst discrimination and glitch classification,” International
TSOperation op = list.iterator().next(); Journal of Modern Physics C, vol. 24, no. 11, 2013.
session.execute(op); [9] W. Hoara and S. Tixeuil, “A language-driven tool for fault injection
if (session.isSolved()) { in distributed systems,” in Grid Computing, 2005. The 6th IEEE/ACM
solved = true;
System.out.println("Troubleshooting
International Workshop on, 2005, pp. 8 pp.–.
finished."); [10] S. Misera, H. Vierhaus, L. Breitenfeld, and A. Sieber, “A mixed language
} fault simulation of vhdl and systemc,” in Digital System Design:
Architectures, Methods and Tools, 2006. DSD 2006. 9th EUROMICRO
} Conference on, 2006, pp. 275–279.
[11] G. Friedrich, M. Stumptner, and F. Wotawa, “Model-based diagnosis of
The table I collects the results/metrics of our comparative hardware designs,” Artificial Intelligence, vol. 111, no. 1–2, pp. 3 – 39,
study between an approach based on Troubles and the one 1999.
[12] J. Rocheteau and J.-L. Boulanger, “Circuit fault & failure description
based on hosted libraries in applying a bayesian methodology language,” in System Safety, 2008 3rd IET International Conference on,
for Computer, Internet Connection and Satellite Systems. It 2008, pp. 1–5.
highlights that Troubles is able to decrease the SLOC figures [13] T. Funabashi, Y. Mizuma, H. Otoguro, and L. Dube, “Fault locator
simulation using models language,” in Energy Management and Power
and, first and foremost, the control density thanks to the fact Delivery, 1998. Proceedings of EMPD ’98. 1998 International Confer-
that model consistency controls are performed at compile-time ence on, vol. 2, 1998, pp. 601–606 vol.2.
directly on DSL files. [14] V. Zivojnovic, S. Pees, and H. Meyr, “Lisa - machine description
language and generic machine model for hw/sw co-design,” in in
V. C ONCLUSIONS Proceedings of the IEEE Workshop on VLSI Signal Processing, 1996,
pp. 127–136.
In this paper we have proposed Troubles, a domain-specific [15] R. Su and W. Wonham, “Probability measure on regular languages and
language oriented to describe and test troubleshooting and its application in fault diagnosis for discrete event systems,” in Control
Conference, 2004. 5th Asian, vol. 1, 2004, pp. 412–419 Vol.1.
failure management algorithms. The language is designed [16] L. Troiano and D. D. Pasquale, “Supporting complexity in modeling
to provide constructs for faults, observations and repairing bayesian troubleshooting,” in ICEIS (2), J. Filipe and J. Cordeiro, Eds.
actions definition. They can be addressed by solvers which SciTePress, 2010, pp. 344–349.

348 2013 International Conference of Soft Computing and Pattern Recognition (SoCPaR)