See

discussions, stats, and author profiles for this publication at: http://www.researchgate.net/publication/272340385

Algebra applied to the multimodeling of fire

protection systems
CONFERENCE PAPER OCTOBER 2014

DOWNLOADS

VIEWS

39

14

4 AUTHORS, INCLUDING:
Houda Chanti

Laurent Thiry

Universit de Haute-Alsace

Universit de Haute-Alsace

2 PUBLICATIONS 0 CITATIONS

30 PUBLICATIONS 34 CITATIONS

SEE PROFILE

SEE PROFILE

Michel Hassenforder
Universit de Haute-Alsace
28 PUBLICATIONS 80 CITATIONS
SEE PROFILE

Available from: Houda Chanti

Retrieved on: 04 July 2015

ALGEBRA APPLIED TO THE MULTIMODELING OF FIRE PROTECTION

SYSTEMS
Houda Chanti, Laurent Thiry, Michel Hassenforder
MIPS EA 2332 - Universite de Haute Alsace, 12 rue des Fr`eres Lumi`ere - 68093 Mulhouse (France)
{houda.chanti, laurent.thiry, michel.hassenforder}@uha.fr

KEYWORDS
Domain Specific Language (DSL), algebra, functional
programming, fire safety.

all the languages required by the certification.

The aim of this paper is to show how the previous concepts can be applied to fire protection field in order to
evaluate the fire safety level in buildings. The paper
is divided into three parts after this introduction. The
part 1 presents the certification process of fire protection, then algebras and the related concepts. The part
2 gives the application of algebras used in the domain
of fire protection with: a) a specification of the various
languages involved in the modeling process, b) the way
have been integrated, and c) the result obtained. Finally, the part 3 summarizes the main points developed
in the paper and gives the perspectives considered.

ABSTRACT
The certification of fire safety systems requires the intervention of many specialists. Each one uses his own language and tools. In order to model such systems, many
models/languages should be formalized and integrated.
In this context, the paper proposes to use algebraic specifications to model, transform and compose the required
Domain Specific Languages (DSLs) required. The various DSLs (architectural, material, simulation, interval,
etc.) required to model the fire safety of a building are
described, combined and illustrated by an example from
a real case.

FIRE MODELING AND ALGEBRA

Dynamical systems for fire

INTRODUCTION

A system is generally abstracted by a state space X, i.e.

a set of variables describing its properties (position or
temperature for instance), a transition function f : X
X describing its dynamics, and an initial state x X.
In the case of discrete time (i.e. time is represented by a
succession of instants n N), the behavior of the system
corresponds to a trajectory in the state space defined by
a recursive equation X(n+1) = f (X(n)) with X(0) = x.
By considering a subset Y X, a typical question is
then: what is the subset Y 0 X such as if x Y 0
then there exists an instant n such as X(n) Y ? As an
illustration, if X represents the temperature T and the
number of persons N for a set of locations (f describes
fire propagation and movements of people), and Y is the
sub-space where (N > 0) (T > 55 C) then a security
property is Y 0 = . In other words, Y represents the
situations where people can die (what is called the
Undesired Event UE) and there is no trajectory that
leads to it. To answer the previous question a great
number of initial states x has to be tried to identify
Y 0 and simulators are required. Moreover, these initial
states are necessary to experiment variations of the
system (function f : X X) to choose the safer one.

The certification of fire protection systems is a complex

task due to the various models to integrate in order to
check that people and materials are under secure conditions. In general, this task involves many specialists
such as an architect (for the plan of the building under study), a chemist (for the properties of the materials used), a firefighter (for the security equipment), an
expert in fire modeling/simulation, etc. The certification then consists mainly in simulating a great number
of various configurations to explore the whole domain
state space and in checking safety/security properties.
So, to get these configurations, many various models
(and languages) have to be specified and integrated.
To proceed, we propose to use a particular branch of
formal methods with algebraic specifications to model,
transform or compose the languages mentioned previously. An algebra is basically defined by a set of functions that inductively generates a set of terms and by
definition a language (or more precisely an abstract syntax of this one that could be attached to a concrete syntax in a second step). The terms are extended by a set
of equations to express properties or to make proofs (e.g.
is the simulated model conform to the specified model
?). Finally, mappings (also known as morphisms) can
be defined to pass from one algebra to another - e.g. to
give a semantics to interpret a language, or to compose

To evaluate the fire safety level in a building, engineers

have to reproduce the phenomena observed in a fire situation which involves many various models (Figure 1)
and fire simulations to get the system behavior. These
1

ones are based on various fire propagation models with

for instance the ones presented in (Hu et al. (2007)) or
(Parry et al. (2003)).

Figure 1: Models in a fire protection system

Input models typically include room dimensions and
building materials, sizes and locations of room openings,
room furnishings characteristics, and fire heat release
rate. Simulator outputs typically include predictions of
upper and lower layer temperatures, the height of the
interface between the upper and lower layers, and combustion gas concentrations and other physical quantities
which can lead to destruction of materials or death of
persons (what defines undesired events).
On these facts, the certification of fire protection system
involves:
Many models to be integrated such as architectural
model (M 1), model describing construction material (M 2), undesired event (M 3), etc. as inputs
to produce an initial state/configuration X(0) (this
one is saved in a specific file and will represent the
simulator input).
The resulting behavior X(n) is used to check safety
properties, and many behaviors have to be considered depending on the initial configuration X(0),
e.g. initial location where a fire starts, or choices of
fire protection sub-systems.
To get the behavior X(n), our institute the CSTB (the
Scientific and Technical Center for Building) has developed a specific fire simulator called CIFI (Bodart and
Curtat (1987)). An example of an input configuration
X(0) for this simulator is given bellow:
- Simulation properties
&MISC JOBNAME=F3 TETAFIN=5400.0 DTETA=0.10 ATOL=1.D-9
RTOL=1.D-7 NSAVE=600 /
&REAC XRAD=0.30D0 COYIELD=0.004D0 SOOTYIELD=0.015D0
NU_C=3.4D0 NU_H=6.2D0 NU_O=2.5D0 /
- Local description
&LOC ID=LOC1 H=2.2 LONG=75. LARG=15. ALT=0. T16INI=21.
E(1)=0.2 LAMBDA(1)=1.6 RHO(1)=2300. CS(1)=1000.
EMIP(1)=0.9 ISOLANT(1)=.FALSE. E(2)=0.2
LAMBDA(2)=1.6 RHO(2)=2300. CS(2)=1000. EMIP(2)=0.9
ISOLANT(2)=.FALSE. /
- Openings description
&OUV ID=OUV1 ALLEGE=0. LINTEAU=1. LARGEUR=3.6
FUITE=0.01 ALT=0. LOCIDS=LOC1,EXT1
CTRLID=ETATOUV1 /
- External temperature
&EXT T=20.0 /
- Fireplace properties

&SBO

ID=FOYER LOCID=LOC1 ZF=0. TVAP=300.

LVAP=1.8D6 AFMAX=12. ILOI=1 RAMP=LIN
MPDOTMAX=0.6944 TPLT=300. TDEC=300. TFIN=3300. /
&END /

The block &MISC describes the global simulation properties. This one is filled by a fire safety engineer. The
block &REAC is obtained from a chemist, and consists
on the parameters of the combustion model. The
block &LOC describes the geometry of one local in a
building and the characteristics of it construction
materials and fire resistance. These parameters are
obtained respectively from an architect and a fire safety
engineer. The &OUV block gives mainly architectural
information, but also leakage (physics) when the
opening is closed. The &SBO block gives information
about the location of the fireplace and also the parameters of the combustion curve based on the fuel material.
The problem is that architects, chemists or fire safety
engineers should use their own (specific) languages, but
they have to follow an error prone complicated language.
A tool making the automatic translation and composition of they own language will be really helpful to generate the initial configuration of the fire simulator. In computer science, languages used by specialists are called
Domain Specific Languages (DSLs): see (Van Deursen
et al. (2000)) for a more precise definition of the concept
and examples. These languages are: 1) based on concepts and features of a domain, and 2) used to describe
and generate programs in a specific field. The use of
DSLs offers the possibility for analysis, optimization and
transformation of models, and has the advantage to enable the reuse of software artifacts, (Biggerstaff (1998);
Fowler (2010)).
Computer science proposes concepts and tools to
specify, transform or compose specific languages. In
particular, a term (or a textual representation of a
model) is simply a sequence of characters that is split
and analyzed to build a value of a particular datatype.
This value is then used for instance to compute another
value or to generate another term for another language
(this is called the interpretation of the term or its
projection to a semantic domain).
As an illustration of a simple DSL, a simple language
for elementary relational expressions is defined by a
comparison (using a lower symbol) between two expressions <Exp> "<" <Exp>, a sequence of two expressions
<Exp> "&&" <Exp>, a string or just a value Val. This
little language can be formalized by the data type Exp.
To manipulate the datatype, some functions must be
defined.
One of the aims of a parser is to store the information analyzed by using a specific datatype. The final
questions that may arise after this presentation are: 1)
how to reason about languages and how to manipulate
them? and 2) what are the concepts, formalisms and

technologies available to describe and then implement

these concepts?
Algebras and functional programming
Algebra is a branch of mathematics that is interested
by structures and their relations. More precisely, an
algebra is defined by a set of sorts S, a set of operations O (also known as the signature of the algebra), a
relation r : O S S, and a set of equations. As
a remark, r(o) = ([s1 , ..., sn ], s) is commonly written
o : s1 ... sn s, and n is called the cardinality of o.
If (n = 0) then o is called a constant of sort s ; cs will
represent the set of all the constants. An algebra inductively defines a set of terms Ts (what corresponds to the
definition of a language) as follow: 1) c cs .c Ts , and
2) ti Tsi .o(t1 , ..., tn ) Ts . An equation is then an
equivalence relation in Ts . These (simplified) definitions
are at the origin of algebraic specifications (a branch of
formal methods used in computer science (Habrias and
Frappier (2006))), and tools such as Maude (Rivera et al.
(2009)) and Haskell, (OSullivan et al. (2008)).
As an illustration, the relational expressions introduced
previously can be formalized by an algebra defined by
a sort Exp and three constructor functions. A function inf : (Exp, Exp) Exp that transforms couple
of expressions to an expression (i.e if x, y Exp than
inf (x, y) Exp). A function and : (Exp, Exp) Exp
that transforms a couple of expressions to an expression
(i.e if x, y Exp than And(x, y) Exp). Functions
val : Int Exp and symb : String Exp that transforms respectively every integer and string values to an
expression(i.e if n Integer than val(n) Exp and
if s String than symb(s) Exp). As explained before, an equivalence relation can be defined on the set
of terms with for instance the commutativity of the and
operator: x, y Exp.and(x, y) = and(y, x). These
equations are necessary to make the specification precise and usable to make proof. As a remark, equations
can be used to define other functions from a specification. For instance, the specification of Exp can be
extended by an evaluation function ev : Exp Bool
satisfying the property: x, y Exp.ev(inf (x, y)) = x
< y, ev(and(x, y)) = ev(x) & ev(y). The function ev is
considered as a particular case of catamorphism (Meijer
et al. (1991)), a concept of Category Theory used to express generic transformations, to calculate programs or
to make proofs (Fokkinga (1992)).
More generally, algebras are related together by
morphisms, i.e. transformations describing how each
operation and sort from the specification is transformed.
In particular, this capability is used to
formally describe the semantics of languages (Goguen
and Malcolm (1996); Hutton (1998)), and is illustrated
in the previous part by the valuation function ev but
many other interpretations could be considered.

An interest brought by algebraic specifications is their

similarities with functional programming where each operation is a function, interpretation functions are higherorder functions (i.e. functions passed as arguments or
as a result of other functions). In particular, the models
presented in the contribution part of the paper are implemented by using the modern functional programming
language Haskell, (Russell and Cohn (2012); OSullivan
et al. (2008)), to propose a tool dedicated to the certification of fire protection systems. In Haskell, constructor
functions are grouped together in a datatype definition
as illustrated below to define the datatype/sort Exp.
Constructors begin with an uppercase letter and functions on a datatype are defined by using pattern matching on each constructor.

data Exp =
|
|
|

Inf(Exp,Exp)
And(Exp,Exp)
Symb String
Val Int

--inf :
--and :
--symb:
--val :

Exp x Exp
Exp x Exp
String
Int

->
->
->
->

Exp
Exp
Exp
Exp

An interesting thing about Haskell is its capability to

integrate a syntax, i.e. a parse function, (Hutton and
Meijer (1998)). As an illustration, a parser for expressions is defined as follow:

digit = (char 0)<|>...<|>(char 9)

letter = (char a)<|>...<|>(char z)
Exp
= do a <- factor
do(string " && "
t <- factor
return (And a t))
<|>
return (Inf a)
id
= do
a <- letter
b <- many1 (letter <|> digit)
return (a++b)
factor = do
a <- id <|> many1 digit
string "<"
b <- id <|> many1 digit
return (Inf b)

A digit is made by one number 0 or (<|>) 1 or 2, ... till

9. A letter is made by one letter of the alphabet. An
identifier always begin with a letter, then followed by
many letters or digits. A factor begin with an identifier
or an integer, followed by the character < and then again
an identifier or an integer. An expression begins with a
factor and can be followed by many other factors separated by the character &&. In this case the function exp
returns the list of factors return (And a t), otherwise
it returns only the first factor return (Inf a).

ALGEBRA FOR FIRE MODELING

System description
As explained above, the description of fire safety systems is based on many various models (Figure 2) for
the architecture of the building, the technical and the
organizational safety measures, etc.

A part of the configuration describes the architecture

of the building (parts LOC and OUV). These data are extracted from an architectural model based on a digital
map. Other information concerning fire place SBO and
construction materials MAT are described in the configuration. They are extracted from a library model created in this purpose. These models are transformed
and merged in a simulation, which represent an extended language of a configuration. It includes intervals
for some quantities and the definition of the undesired
events too.

Figure 2: Generation process of configurations

Figure 3: Process of the evaluation of fire safety level
Each model is based on a specific language and its concrete syntax is abstracted by a specific datatype. The
fire safety evaluation system proposed consists on a generator (based on different models and simulation), a fire
simulator and a checker.
The evaluation of the safety level in a building, needs to
study several configurations which is the goal of the generator. It automatically build many configurations and
randomly select values into intervals which constitute
the input files of the fire simulator. Each language must
be abstracted by a datatype and functions to manipulate and transform terms. In particular, the example of
configuration file given in the previous section can be
Now, the concrete syntax is attached to a datatype to
store information contained in the input file. More precisely, a configuration can be abstracted by a list ([ ])
composed of a string (component identifier), and a list
of properties; a property is composed by many string
couples for the property identifier and the value of that
property. This definition leads to the Haskell code:
data Config = Config[(String, [Prop])]
data Prop
= Prop(String, String)

What leads to the set of sorts S

=
{Conf ig, P rop, String}. Some functions must be defined to transform and manipulate the datatype. As for
instance parseConf ig :: String Conf ig which transforms a string into a config sort, unparseConfig which
make the inverse: unparseConf ig :: Conf ig String,
it transforms a config into a string. The function
getId :: Conf ig [String] returns the list of
all component identifiers of a configuration, and
getP rop :: (Conf if, String) |P rop] returns
the properties list of a component in a configuration. what defines a list of algebra operations:
O = {parseConf ig, unparseConf ig, getId, getP rop}.

The simulation is then sent to the generator which generates several configurations. Theses latest are processed by the simulator which generates physical quantities. The simulation results are controlled to check
if some conditions (the definition of undesired events)
has been reached or not (figure 3). More precisely, the
evaluation of the safety level in a building is based on
the frequency occurrence of the U E. The checker is in
charge of this task.
The architectural model
Based on a digital map, information concerning the geometry of the building, dimension and position of the
different openings are extracted from an IFC (IFC: Industry Foundation Classes, is a standard which allows
building simulation software to automatically acquire
building geometry and other building data from project
models) format (Spearpoint (2006); Martens and Herbert (2004)), one of the specific languages used by architects. An example of an IFC file is:
#9512= c(3y21AUC9X4yAqzLGUny16E,
#16,Story,$,$,
#9509,
$,$,.ELEMENT.,6200.);
#9509= IFCLOCALPLACEMENT(#115,#9506);
#9506= IFCAXIS2PLACEMENT3D(#9502,#9498,#9494);
#9502= IFCCARTESIANPOINT((0.,0.,6200.));
#9498= IFCDIRECTION((0.,0.,1.));
#9494= IFCDIRECTION((1.,0.,0.));
data Ifc = Ifc [(Int, String, Value)]

A Value is either an integer (for references), a string

(for values) or a pair composed of a string and a list of
values (for sub components):
data Value = I Int | S String | V (String,[Value])

This leads to the set of sorts S

=
{IF C, Int, String, V alue}. In order to transform a
string into an Ifc sort, a specific parser has been defined:
parseIf c :: String If c!, an unparse transforms an
Ifc to a string: unparseIF C :: If c String. Utility
functions has been defined to extracts particular information component for instance, the function get, concepts and elements. What leads to the set of operations
O = {parseIf c, getId, getP rop, concepts, elements}.
These operations define the operation set of the algebra.
They can be defined in Haskell as follow:
concepts::
elements::
getId
::
getProp ::

Ifc
-> [String]
(Ifc, String) -> [Int]
(Ifc, Int)
-> (String,[Value])
(Ifc, String) -> (String,[Value])

The concepts function returns all the Ifc concepts,

elements returns a list of indexes of specific concept
and the getId or getProp functions return the properties of a specific index or a specific component. The
next step is to define the properties of these functions
(or the axioms of these relations).
concepts
concepts
concepts
elements
elements

[]
f
cs
([], t)
(f, t)

=
=
=
=
=

[]
map (snd
[c where
[]
map (fst
and
and

f where snd(a,b,c) = b)
(k, c, v)<- cs]
f where (t== snd f
fst (a,b,c) = a
snd (a,b,c) = b ))

The concepts of an IFS returns the second element of

the triplet composing the Ifc. The indexes of a specific
concept f if the first element of the triplet composing an
Ifc where the second element of that triplet is equal to
t.
Materials and fireplaces
Some information dont change from a simulation to another, for example characteristics of construction materials M AT (information about the stability of materials
against fire) and parameters which describe a fireplace
SBO (combustion curve of potential fireplaces). These
properties are also needed to make a configuration (figure 2). In this context we propose to create libraries
of SBO and M AT . The first one (SBO) lists and describes the combustion curves of potential fireplaces and
the second one (MAT)describes the construction materials which informs about the tenability of the walls. An
example of the two libraries is:
&MAT ID=WOOD E=0.20 LAMBDA=1.6 RHO=2300. CS=1000.
EMIP=0.9 ISOLANT=.FALSE. /
&SBO ID=CHAIR ZF=0. TVAP=300. LVAP=1.8D6 AFMAX=5.
ILOI=2 RAMP=LIN TPLT=600. MPDOTMAX=0.1
TDEC=1800. TFIN=2700. /

The concrete aspects of these languages are abstracted

by two datatypes: MAT and SBO, which can be seen as a
list [] of components and declared in Haskell as follow:

data
data
data
data

SBO = Sbo[(String,Params)]
MAT = Mat[(String,Params)]
Params = Par[(String, Value)]
Value = R Real | S String

Each component is defined by a name (String) and a

list of parameters (Params). Each one is characterized
by an identifier (String) and a value (Real), what leads
to a set of sorts used to define the SBO library S =
{SBOP arams, V alue, String, Real}, and M AT library
SO = {M AT P arams, V alue, String, Real}. Utility
functions has been defines to encode the grammars and
extract particular components as for for instance the
functions
parseLib,
get,
components and insert which
make the operations of the algebra (O
=
{parseLib, get, components, insert}).
A list of relations is encoded in Haskell as follow:
parseSbo and parseMat, getSbo and getMat, insertSbo
and insertMatwhich make operations of the two algebras (O = {parseSbo, getSbo, insertSbo} and (O =
{parseM at, getM at, insertM at}). The list of relations
is encoded in Haskell as follow:
parseSbo
getSbo
insertSbo
parseMat
getMat
insertMat

::
::
::
::
::
::

String
(SBO, String)
(String, Params)
String
(SBO, String)
(String, Params)

->
->
->
->
->
->

SBO
[Params]
SBO
MAT
[Params]
MAT

The functions parseSboand parseMat are specific parsers

that transforms a string to SBO or MAT sorts. The
functions get returns a list of parameters corresponding
to a specific library by an identifier (string) and the insert functions to insert specific components in a specific
library. The next step is to describe the behavior of
these functions/relations by defining their properties or
axioms, for example the SBO manipulation functions:
getSbo []
getSbo lb id

= []
= filter (par lb)
where par l = (fst l ==id)
insertSbo Sbo(s,p)[] = [(s, p)]
insertSbo Sbo(s,p) lb = lb ++ [(s, p)]

The function filter process on the library lib by applaying the function par which returns the list of parameters
corresponding to a specific identifier (id). The insertSbo
insert a new component in a library by concatenating
(at the end of the list) the existing library with the new
element (++).
The Undesired Event (UE)
An undesired event (UE) is defined by some safety properties. It is specified as the last event in a chain of
events with devastating impact on one or more individuals, ecosystems or materials. It is strongly correlated
to the thermal conditions, the amount of toxic gases and
smokes, and the pressure in a local. It is considered as

an extreme condition. An UE can be the reaching of a

certain temperature in the upper layer (TU ) of a local
(gas temperature), a certain height of the smoke or the
achievement of a critical pressure.
Based on their experience, fire engineer define manually
undesired events (with simple conditions). The evaluation of fire safety level is highly correlated with the frequency occurrence of the undesired events (UE) which
reflects conditions leading to the death of a person or
destruction of material. Some examples of undesired
events are:
room == 2 && TU > 550
room == 1 && teta < 350 && P > 100
room == 1 && teta < 650 && TU > 450 && ZD < 0.55

In order to model the concrete aspect of this language,

manipulate and transform it, a data type UE has been
defined as a list ([]) as follow:
data UE
= UE[(Params)]
data Params = Par[(Op, Factor,
data Op
= Inf String | Sup
| Equ String | Amp
data Factor = Id String | Val

Factor)]
String
Params
Float | Room Int

To manipulate an undesired event, the description of

utility functions behavior is given by the following equations:
insert []
=
insert ev (o,s,v)=
quantity []
=
quantity u i
=

[]
ev++[(o,s,v)]
[]
filter (rm u)
where rm (o,s,v) = (s=="Room" && v ==i)
local []
= []
local u
= filter (ro u)
where ro (o,s,v) = (s=="Room")
eval(Inf(i,s,v),c,t)
= c(t,s) < v
eval(Sup(i,s,v),c,t)
= c(t,s) > v
eval(Amp(i,e1,e2),c,t) = eval(e1,c,t) && eval(e2,c,t)

Insert an empty list returns an empty list, while insert a

triplet in a list returns a list composed with concatenation (++) of the new element and list elements. Quantity returns the list of parameters to be checkes in a
specific room. the function locar returns the list of all
locals in undesired events. Finally the parseU E function is used with the eval function to get the checker
component: checker = eval parseU E

An undesired event is defined by a list of parameters

(Params) defining the room nuber and some conditions.
The Params type is a list of Strings (Equ, Inf, Sup
or Amp) to model the room identifier (Int), comparison between physical quantities (String) and values
(Float) (Inf String or Sup String) and/or to compose them with a conjunction (Amp Params) in the same
room. In Haskell, the data type UE can also be defined
using its constructors. The result of the simulator is
used to define a context function to get the value of a
particular symbol.

Simulation

type Time
= Integer
type Context = (Time, String) -> Float

&MISC NAME=conf PLAN=room.ifc MAT=mat.data

SBO=sbo.data MAX_CONFIGURATION=8 ATOL=1.D-9
DTETA=1. TETAFIN=3600. RTOL=1.D-7 NSAVE=60/
&REAC REAC=REAC_SIMPLE /
&EXT T= 20.0 DP(1)=0./
&LOC ID=LOC1 GEO=LOC1 MAT=CONCRETE_1 T16INI=20.1 /
- A door
&OUV ID=OUV1 GEO=OUV1 ON_INI=.FALSE. /
- Windows
&OUV ID=OUV2 GEO=OUV2 ON_INI=.TRUE. /
&OUV ID=OUV3 GEO=OUV3 ON_INI=.FALSE. /
&SBO ID=FOYER LOCID=LOC1 SBO=BOX/
&ENS ID=GOODS LOCID=LOC1 EXPR=TMZH > 600 /
&ENS ID=HUMAN LOCID=LOC1
EXPR=TMZH > 180 && ZD < 1.8/
&END /

The set of sorts used to specify an undesired event is:

S = {U E, P arams, Op, F actor, T ime, Context}. Utility functions are defined to manipulate the data type
UE. The function parseU E is a specific parser that
transforms a string to an UE sort. The function eval
is defined to evaluate an event in a context and at
a precise instant and insert is defined to add a new
undesired event in the UE list. Quantity and local
functions extract specific information from the undesired events list, respectively list of parameters in a
specific room and rooms in which we want to verify if
the undesired event happened or not [Int]. The list of
these functions constitutes the operations of the algebra: S = {parseU E, eval, insert, quantity, local}. The
definition of these functions which defines the relations
part of the algebra is given by:
parseUE
eval
insert
quantity
local

::
::
::
::
::

String
-> UE
(UE, Context, Time)
-> Bool
(Time, Factor, Factor, UE) -> UE
(UE, Int)
-> [Params]
UE
-> [int]

The specific datatypes presented above and abstracting

different models needed to describe the fire evaluation
safety system and merged into a simulation. This latest represent the base of a configuration. It contains
the same kind of information as a configuration, and
includes references to architectural model, library and
the definition of undesired events too. An example of a
simulation is:

The grammar of a configuration has been extended to

integrate the other models; we call it simulation. First
it refers the models presented above as for instance
the PLAN, the libraries and informs how many configuration to be generated in the bloc MISC and then
the fire places and undesired events. The link between
the property and the architectural model is made by
a property called GEO. The libraries are integrated
as entire blocs in the simulation. The simulation is

coded and attached to a datatype Simu, which is abstracted by a list of a string for the component identifier (e.g. MISC, LOC,OUV), and a list of properties.
Each property is made by a couple of property identifiers abstracted by a string (e.g. ID, PLAN, GEO) and
the value of that identifier. The formalization of the
datatype Simu leads to the set of sorts S specifying a
simulation S = {Simu, P rop, V alue}. The definition of
a simulation is coded with Haskell as follow:
data Simu
data Prop
data Value

= Simu[(String, [Prop])]
= Prop(String, Value)
= V String | IS Float | I Int

A parser is defined to translate a string to a

Simu datatype: parseSimu :: String Simu
and an unparser to rewrite a Simu in another format unparseSimu :: Simu String.
Some
other functions are defined to manipulate the
datatype what defines the list of operations O =
{parseSimu, unparseSimu, get, elements}. The function get returns a list of properties attached to a component in a simulation get :: (Simu, String) [P rop]
and elements returns the list of components of a simulation elements :: Simu [String]. To manipulate a
simulation, the description of utility functions behavior
is given by the following equations:
get []
=
get Simu(a,p) s
=
elements []
=
elements Simu(a,p)=

[]
map (snd(s,p) where snd(a,x:xs)=xs)
[]
map (fst(a,p) where fst(s,x:xs)=s)

To get the properties p of a simulation, we extract the

second element of a Simu which is a list (x:xs) using the
function snd, and the function Haskell map apply the
latest function on all simulation elements. The same
process to define the function elements, but we extract
the first elements (using the function fst) of pairs making
a simulation.
Intervals
In order to make random selections of values, an interval
language is defined. An interval substitutes a simple
value by a range of values and the definition of the range
is enclosed into brackets. Examples are:
[ 18.0 .. 38.0 / 2.0 ]
[BOX,TABLE,CHAIR]
[15.0, 20.1, 25.0]
LOC1
60

The first example defines a range from 18.0 to 38.0 by

(additive) step of 2.0, the second and third ones are
enumeration of simple values: either string or numbers.
Concepts of this language are coded and attached to a
datatype Inter defined in Haskell as follow:
data Inter

= IV [String] | IS (Float, Float, Float)

| V String | F Float

The datatype Inter is defined by four constructors with

as parameters a list of a strings (IV [String]) to enumerate the values of the interval, a triplet of floats
(IS(F loat, F loat, F loat)) referring to the initial, final
and step values or just a string (V String) or a float
(V F loat).
Global integration
A configuration needs many models (architectural,
fireplace, construction materials and undesired
events) to be made. Each one is abstracted by a
datatype, and transformed to be complaint with
the simulation (using unparse functions). Lets define a transformation T which transforms models
(Mi ) to an other one (M0 ), with T : Mi M0 .
In this context the models Mi required to make a
simulation are IFC, MAT, SBO, undesired events
and the interval, the destination is a simulation
(T : (Archi, M AT, SBO, U E, Inter) Simu). The
simulation refers transformed models basing on their
specific datatypes and making a composition of these
latter, what leads to T (If c, Lib, U E, Inter)=T (If c)
T (Lib) T (U E) T (Inter). All values in it can be
intervals, what allows to take randomly several values
to make many configuration.
Based on datatypes and their specific functions, the simulation extracts data necessary to make a configuration
(e.g. the architecture of the locals and openings). Some
manipulation functions are defined as for instance the
function read which reads the content of the external
files simulation, Ifc and lib. Based on specific parsers,
the simulation file refers the geometry, Mat and Sbo.
The binding between the simulation and the other specific languages is made by referencing components in
the other models (external files), getters of the specific
datatypes select and extract these components. The
simulation is then sent to the generator which get randomly a value in each interval to make a configuration
and then replace the references by the values extracted.
These steps are repeated many times to produce several
configurations (input to the fire simulator). The following code reads the external files, then transforms their
contents in specific types (Ifc, Mat, ...), and generates
an initial state (ctx[0]). By applying this initial state
on the architectural and fire models, it calculates a new
state and save it in result file. This step is repeated
many times (N times).
simu
= parseSimu(read("simulation.txt"))
archi
= parseIfc(read("archi.txt"))
mat
= parseMat(read("mat.txt"))
sbo
= parseSbo(read("sbo.txt"))
model
= parse(read("model.txt"))
for i = 1 to get(ctx, "MAX_CONFIGURATION")
config = generate-random(seq(simu, archi, mat, sbo))
ctx[0] = exec(config,[])
for n
= 1 to get(config,"N")

ctx[n] = exec(seq(model, config), ctx[n-1])

write(config ,"config-"+i+".txt")
write(ctx
,"result-"+i+".txt")

The context ctx contains successive values of the

quantities calculated by the model for example the temperature in upper layer. The evolution state of the system is saved in result- files. The config- files contain
the different configurations generated by the generator.
The result- and config- files, joined to the definition
of the undesired events are sent to the checker to verify
if the undesired events have been reached or not. The
results of checking and the fire safety level are correlated to the occurrence frequency of the UE. The safety
level is at least quantified by calculating the achievement
rate of UE based on the total number of configurations
(MAX CONFIGURATION). The aim of evaluating
fire safety level in building is to protect human lives in
the case of a fire. In fire situation unexpected conditions
affect fire behavior as for instance the reaction of a human in in a fire room (e.g. human movement between
rooms or opening doors and windows). In this case the
SBO bloc will have several behaviors depending on time
and conditions. At the moment these cases are not considered to make a configuration, but the next step of this
work is to integrate the human behavior in the evaluation process. In this case a human specific language
must be defined and integrated to the simulation.
CONCLUSION
In order to integrate the different models and specific
languages required in the field of fire safety on a unique
platform, this paper proposed algebra and functional
programming. Concepts of algebra allow the definition
of higher level function for transformation, integration
and composition of several models that do not necessarily use the same language. The abstract syntax and a
concrete syntax of the specific languages are described.
The simulation language which integrates all of them
into one comprehensive set is described too. Evaluation
of a fire safety level requires a lot of configurations to
study. To generate them randomly, an interval language
extension is combined with all of the previous languages.
The expected tool is now able to study building, and the
next step will be to introduce a new DSL about human
behaviors.

Publication - Workshop on Fire Modeling - Berlin,

West Germany, vol. 104.
Fokkinga M., 1992. A Gentle Introduction to Category
Theory - the calculational approach. In Lecture Notes
of the STOP 1992 S ummerschool on Constructive
Algorithmics, University of Utrecht. 172 of Part 1.
Fowler M., 2010. Domain-Specific Languages. Pearson
Education. ISBN 9780131392809.
Goguen J.A. and Malcolm G., 1996. Algebraic Semantics of Imperative Programs. MIT Press, Cambridge,
MA, USA.
Habrias H. and Frappier M., 2006. Software Specification Methods. Wiley-ISTE, NY, USA.
Hu L.H.; Fong N.K.; Yang L.Z.; Chow W.K.; Li Y.Z.;
and Huo R., 2007. Modeling fire-induced smoke spread
and carbon monoxide transportation in a long channel: Fire Dynamics Simulator comparisons with measured data. Journal of Hazardous Materials, 140, no.
12, 293298. ISSN 0304-3894.
Hutton G., 1998. Fold and Unfold for Program Semantics. In In Proc. 3rd ACM SIGPLAN International
Conference on Functional Programming. ACM Press,
280288.
Hutton G. and Meijer E., 1998. Monadic parsing in
Haskell. 8, no. 4, 437444.
Martens B. and Herbert P., 2004. ArchiCAD. Springer.
ISBN 9783211407554.
Meijer E.; Fokkinga M.; and Paterson R., 1991. Functional Programming with Bananas, Lenses, Envelopes
and Barbed Wire. Springer-Verlag, 124144.
OSullivan B.; Goerzen J.; and Stewart D., 2008. Real
World Haskell. OReilly Media, Inc., 1st ed.
Parry R.; Wade C.A.; and Spearpoint M., 2003. Implementing a Glass Fracture Module in the BRANZFIRE
Zone Model. Journal of Fire Protection Engineering,
13, no. 3, 157183. ISSN 1042-3915, 1532-172X.
Rivera J.; Duran F.; and Vallecillo A., 2009. Formal
Specification and Analysis of Domain Specific Models
Using Maude. 85, no. 11, 778792. ISSN 0037-5497,
1741-3133.

REFERENCES

Russell J. and Cohn R., 2012. Haskell (programming

Language). Book on Demand. ISBN 9785510997262.

Biggerstaff T., 1998. A perspective of generative reuse.

Annals of Software Engineering, 5, no. 1, 169226.
ISSN 1022-7091, 1573-7489.

Spearpoint M.J., 2006. Fire engineering properties

in the IFC building product model and mapping to
BRANZFIRE. International Journal on Engineering
Performance-Based Fire Codes, 134147.

Bodart X. and Curtat M., 1987. CIFI Computer Code:

Air and Smoke Movement During a Fire in a Building With Ventilation Ducts Networks Equipment. CIB

Van Deursen A.; Klint P.; and Visser J., 2000. DomainSpecific Languages: an annotated bibliography. SIGPLAN Not, 35, no. 6, 2636. ISSN 0362-1340.