Algebra Applied to the Multimodeling of Fire Protection Systems

7/23/2019 Algebra Applied to the Multimodeling of Fire Protection Systems

1/9

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

Algebra applied to the multimodeling of fireprotection systems

CONFERENCE PAPER OCTOBER 2014

DOWNLOADS

39VIEWS

14

4 AUTHORS, INCLUDING:

Houda Chanti

Universit de Haute-Alsace

2PUBLICATIONS 0CITATIONS

SEE PROFILE

Laurent Thiry



SEE PROFILE

Michel Hassenforder



SEE PROFILE

Available from: Houda Chanti

Retrieved on: 04 July 2015
http://www.researchgate.net/profile/Michel_Hassenforder?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_7http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_1http://www.researchgate.net/profile/Michel_Hassenforder?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_7http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/profile/Michel_Hassenforder?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_5http://www.researchgate.net/profile/Michel_Hassenforder?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_4http://www.researchgate.net/profile/Laurent_Thiry?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_7http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/profile/Laurent_Thiry?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_5http://www.researchgate.net/profile/Laurent_Thiry?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_4http://www.researchgate.net/profile/Houda_Chanti?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_7http://www.researchgate.net/institution/Universite_de_Haute-Alsace?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_6http://www.researchgate.net/profile/Houda_Chanti?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_5http://www.researchgate.net/profile/Houda_Chanti?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_4http://www.researchgate.net/?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_1http://www.researchgate.net/publication/272340385_Algebra_applied_to_the_multimodeling_of_fire_protection_systems?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_3http://www.researchgate.net/publication/272340385_Algebra_applied_to_the_multimodeling_of_fire_protection_systems?enrichId=rgreq-d7486081-6bf1-4570-af2d-c1ba8fa0fb22&enrichSource=Y292ZXJQYWdlOzI3MjM0MDM4NTtBUzoyNDYzMzg4ODEzMjMwMTFAMTQzNTc0MzE3NTEwMQ%3D%3D&el=1_x_2


2/9

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 Freres Lumiere - 68093 Mulhouse (France){houda.chanti, laurent.thiry, michel.hassenforder}@uha.fr

KEYWORDS

Domain Specific Language (DSL), algebra, functionalprogramming, fire safety.

ABSTRACT

The certification of fire safety systems requires the inter-vention of many specialists. Each one uses his own lan-

guage and tools. In order to model such systems, manymodels/languages should be formalized and integrated.In this context, the paper proposes to use algebraic spec-ifications to model, transform and compose the requiredDomain Specific Languages (DSLs) required. The vari-ous DSLs (architectural, material, simulation, interval,etc.) required to model the fire safety of a building aredescribed, combined and illustrated by an example froma real case.

INTRODUCTION

The certification of fire protection systems is a complextask due to the various models to integrate in order tocheck that people and materials are under secure con-ditions. In general, this task involves many specialistssuch as an architect (for the plan of the building un-der study), a chemist (for the properties of the materi-als used), a firefighter (for the security equipment), anexpert in fire modeling/simulation, etc. The certifica-tion then consists mainly in simulating a great numberof various configurations to explore the whole domainstate 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 offormal methods with algebraic specifications to model,transform or compose the languages mentioned previ-ously. An algebra is basically defined by a set of func-tions that inductively generates a set of terms and bydefinition a language (or more precisely an abstract syn-tax of this one that could be attached to a concrete syn-tax in a second step). The terms are extended by a setof 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) canbe defined to pass from one algebra to another - e.g. to

give a semantics to interpret a language, or to compose

all the languages required by the certification.

The aim of this paper is to show how the previous con-cepts can be applied to fire protection field in order toevaluate the fire safety level in buildings. The paperis divided into three parts after this introduction. Thepart 1 presents the certification process of fire protec-tion, then algebras and the related concepts. The part2 gives the application of algebras used in the domain

of fire protection with: a) a specification of the variouslanguages involved in the modeling process, b) the wayhave been integrated, and c) the result obtained. Fi-nally, the part 3 summarizes the main points developedin the paper and gives the perspectives considered.

FIRE MODELING AND ALGEBRA

Dynamical systems for fire

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 functionf :XXdescribing its dynamics, and an initial state x X.In the case of discrete time (i.e. time is represented by asuccession of instantsn N), the behavior of the systemcorresponds to a trajectory in the state space defined bya recursive equationX(n+1) =f(X(n)) withX(0) =x.

By considering a subset Y X, a typical question isthen: what is the subset Y0 X such as if x Y0then there exists an instant n such asX(n) Y? As anillustration, ifX represents the temperature T and thenumber of persons N for a set of locations (f describesfire propagation and movements of people), andYis thesub-space where (N >0)(T >55C) then a securityproperty is Y0 = . In other words, Y represents thesituations where people can die (what is called theUndesired Event UE) and there is no trajectory thatleads to it. To answer the previous question a greatnumber of initial states x has to be tried to identifyY0 and simulators are required. Moreover, these initialstates are necessary to experiment variations of thesystem (function f :X X) to choose the safer one.

To evaluate the fire safety level in a building, engineershave to reproduce the phenomena observed in a fire sit-uation which involves many various models (Figure 1)

and fire simulations to get the system behavior. These

1


3/9

ones are based on various fire propagation models withfor 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 andbuilding materials, sizes and locations of room openings,room furnishings characteristics, and fire heat releaserate. Simulator outputs typically include predictions ofupper and lower layer temperatures, the height of theinterface between the upper and lower layers, and com-bustion gas concentrations and other physical quantitieswhich can lead to destruction of materials or death ofpersons (what defines undesired events).On these facts, the certification of fire protection systeminvolves:

Many models to be integrated such as architecturalmodel (M1), model describing construction mate-rial (M2), undesired event (M3), etc. as inputsto produce an initial state/configuration X(0) (thisone is saved in a specific file and will represent thesimulator input).

The resulting behavior X(n) is used to check safetyproperties, and many behaviors have to be consid-ered depending on the initial configuration X(0),e.g. initial location where a fire starts, or choices offire protection sub-systems.

To get the behavior X(n), our institute the CSTB (theScientific and Technical Center for Building) has devel-oped a specific fire simulator called CIFI (Bodart andCurtat (1987)). An example of an input configurationX(0) for this simulator is given bellow:

- Simulation properties

&MISC JOBNAME=F3 TETAFIN=5400.0 DTETA=0.10 ATOL=1.D-9RTOL=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.2LAMBDA(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 prop-erties. This one is filled by a fire safety engineer. The

block &REAC is obtained from a chemist, and consistson the parameters of the combustion model. Theblock &LOC describes the geometry of one local in abuilding and the characteristics of it constructionmaterials and fire resistance. These parameters areobtained respectively from an architect and a fire safetyengineer. The &OUV block gives mainly architecturalinformation, but also leakage (physics) when theopening is closed. The &SBO block gives informationabout the location of the fireplace and also the param-eters of the combustion curve based on the fuel material.

The problem is that architects, chemists or fire safetyengineers should use their own (specific) languages, butthey have to follow an error prone complicated language.A tool making the automatic translation and composi-tion of they own language will be really helpful to gener-ate the initial configuration of the fire simulator. In com-puter science, languages used by specialists are calledDomain Specific Languages (DSLs): see (Van Deursenet al. (2000)) for a more precise definition of the conceptand examples. These languages are: 1) based on con-cepts and features of a domain, and 2) used to describeand generate programs in a specific field. The use ofDSLs offers the possibility for analysis, optimization and

transformation of models, and has the advantage to en-able the reuse of software artifacts, (Biggerstaff (1998);Fowler (2010)).Computer science proposes concepts and tools tospecify, transform or compose specific languages. Inparticular, a term (or a textual representation of amodel) is simply a sequence of characters that is splitand analyzed to build a value of a particular datatype.This value is then used for instance to compute anothervalue or to generate another term for another language(this is called the interpretation of the term or itsprojection to a semantic domain).

As an illustration of a simple DSL, a simple languagefor elementary relational expressions is defined by acomparison (using a lower symbol) between two expres-sions "


4/9

technologies available to describe and then implementthese concepts?

Algebras and functional programming

Algebra is a branch of mathematics that is interested

by structures and their relations. More precisely, analgebra is defined by a set of sorts S, a set of opera-tions O (also known as the signature of the algebra), arelation r : O S S, and a set of equations. Asa remark, r(o) = ( [s1,...,sn], s) is commonly writteno: s1 ... sn s, and n is called the cardinality ofo.If (n = 0) then o is called a constant of sort s ; cs willrepresent the set of all the constants. An algebra induc-tively defines a set of termsTs (what corresponds to thedefinition of a language) as follow: 1)c cs.c Ts, and2) ti Tsi .o(t1,...,tn) Ts. An equation is then anequivalence relation inTs. These (simplified) definitionsare at the origin of algebraic specifications (a branch of

formal methods used in computer science (Habrias andFrappier (2006))), and tools such as Maude (Rivera et al.(2009)) and Haskell, (OSullivan et al. (2008)).As an illustration, the relational expressions introducedpreviously can be formalized by an algebra defined bya sort Exp and three constructor functions. A func-tion inf : (Exp,Exp) Exp that transforms coupleof expressions to an expression (i.e if x, y Exp thaninf(x, y) E xp). A function and: (Exp,Exp) E xpthat transforms a couple of expressions to an expression(i.e if x, y Exp than And(x, y) Exp). Functionsval : I nt E xpand symb: String E xpthat trans-

forms respectively every integer and string values to anexpression(i.e if n Integer than val(n) Exp andif s String than symb(s) Exp). As explained be-fore, an equivalence relation can be defined on the setof terms with for instance the commutativity of the andoperator: x, y Exp.and(x, y) = and(y, x). Theseequations are necessary to make the specification pre-cise and usable to make proof. As a remark, equationscan be used to define other functions from a specifi-cation. For instance, the specification of Exp can beextended by an evaluation function ev : Exp Boolsatisfying the property: x, y Exp.ev(inf(x, y)) = x< y, ev(and(x, y)) =ev(x) & ev(y). The function ev isconsidered as a particular case of catamorphism (Meijeret al. (1991)), a concept of Category Theory used to ex-press generic transformations, to calculate programs orto make proofs (Fokkinga (1992)).More generally, algebras are related together bymorphisms, i.e. transformations describing how eachoperation and sort from the specification is trans-formed. In particular, this capability is used toformally describe the semantics of languages (Goguenand Malcolm (1996); Hutton (1998)), and is illustratedin the previous part by the valuation function ev butmany other interpretations could be considered.

An interest brought by algebraic specifications is theirsimilarities with functional programming where each op-eration is a function, interpretation functions are higher-order functions (i.e. functions passed as arguments oras a result of other functions). In particular, the modelspresented in the contribution part of the paper are im-

plemented by using the modern functional programminglanguage Haskell, (Russell and Cohn (2012); OSullivanet al. (2008)), to propose a tool dedicated to the certifi-cation of fire protection systems. In Haskell, constructorfunctions are grouped together in a datatype definitionas illustrated below to define the datatype/sort Exp.Constructors begin with an uppercase letter and func-tions on a datatype are defined by using pattern match-ing on each constructor.

data Exp = Inf(Exp,Exp) --inf : Exp x Exp -> Exp

| And(Exp,Exp) --and : Exp x Exp -> Exp

| Symb String --symb: String -> Exp| Val Int --val : Int -> Exp

An interesting thing about Haskell is its capability tointegrate a syntax, i.e. a parse function, (Hutton andMeijer (1998)). As an illustration, a parser for expres-sions is defined as follow:

digit = (char 0)...(char 9)letter = (char a)...(char z)

Exp = do a


5/9

ALGEBRA FOR FIRE MODELING

System description

As explained above, the description of fire safety sys-tems is based on many various models (Figure 2) for

the architecture of the building, the technical and theorganizational safety measures, etc.

Figure 2: Generation process of configurations

Each model is based on a specific language and its con-crete syntax is abstracted by a specific datatype. Thefire safety evaluation system proposed consists on a gen-erator (based on different models and simulation), a firesimulator and a checker.The evaluation of the safety level in a building, needs tostudy several configurations which is the goal of the gen-erator. It automatically build many configurations andrandomly select values into intervals which constitutethe input files of the fire simulator. Each language mustbe abstracted by a datatype and functions to manipu-

late and transform terms. In particular, the example ofconfiguration file given in the previous section can beNow, the concrete syntax is attached to a datatype tostore information contained in the input file. More pre-cisely, a configuration can be abstracted by a list ([ ])composed of a string (component identifier), and a listof properties; a property is composed by many stringcouples for the property identifier and the value of thatproperty. 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 ={Config, P rop, String}. Some functions must be de-fined to transform and manipulate the datatype. As forinstanceparseConfig:: String Configwhich trans-forms a string into a config sort, unparseConfig whichmake the inverse: unparseConfig:: Config String,it transforms a config into a string. The functiongetId :: Config [String] returns the list ofall component identifiers of a configuration, andgetProp :: (Confif, String) |Prop] returnsthe properties list of a component in a configu-ration. what defines a list of algebra operations:O= {parseConf ig, unparseConf ig, getId, getP rop}.

A part of the configuration describes the architectureof the building (parts LOC and OUV). These data are ex-tracted from an architectural model based on a digitalmap. Other information concerning fire place SBO andconstruction materialsMAT are described in the configu-ration. They are extracted from a library model cre-

ated in this purpose. These models are transformedand merged in a simulation, which represent an ex-tended language of a configuration. It includes intervalsfor some quantities and the definition of the undesiredevents too.

Figure 3: Process of the evaluation of fire safety level

The simulation is then sent to the generator which gen-erates several configurations. Theses latest are pro-cessed by the simulator which generates physical quan-tities. The simulation results are controlled to checkif some conditions (the definition of undesired events)has been reached or not (figure 3). More precisely, theevaluation of the safety level in a building is based onthe frequency occurrence of the U E. The checker is incharge of this task.

The architectural model

Based on a digital map, information concerning the ge-ometry of the building, dimension and position of thedifferent openings are extracted from an IFC (IFC: In-dustry Foundation Classes, is a standard which allowsbuilding simulation software to automatically acquirebuilding geometry and other building data from projectmodels) format (Spearpoint (2006); Martens and Her-bert (2004)), one of the specific languages used by ar-chitects. 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 ofvalues (for sub components):

data Value = I Int | S String | V (String,[Value])


6/9

This leads to the set of sorts S ={IF C,I nt, String, V alue}. In order to transform astring into an Ifc sort, a specific parser has been defined:parseIf c :: String If c!, an unparse transforms anIfc to a string: unparseIFC :: If c String. Utilityfunctions has been defined to extracts particular infor-

mation component for instance, the function get, con-cepts and elements. What leads to the set of operationsO = {parseIf c, getI d, getP rop, concepts, elements}.These operations define the operation set of the algebra.They can be defined in Haskell as follow:

concepts:: Ifc -> [String]

elements:: (Ifc, String) -> [Int]

getId :: (Ifc, Int) -> (String,[Value])getProp :: (Ifc, String) -> (String,[Value])

The concepts function returns all the Ifc concepts,elements returns a list of indexes of specific conceptand the getId or getProp functions return the prop-

erties of a specific index or a specific component. Thenext step is to define the properties of these functions(or the axioms of these relations).

concepts [] = []

concepts f = map (snd f where snd(a,b,c) = b)

concepts cs = [c where (k, c, v) SBO

getSbo :: (SBO, String) -> [Params]insertSbo :: (String, Params) -> SBO

parseMat :: String -> MAT

getMat :: (SBO, String) -> [Params]insertMat :: (String, Params) -> MAT

The functionsparseSboandparseMatare specific parsersthat transforms a string to SBO or MAT sorts. Thefunctionsget returns a list of parameters correspondingto a specific library by an identifier (string) and the in-sert functions to insert specific components in a specificlibrary. The next step is to describe the behavior ofthese functions/relations by defining their properties oraxioms, 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 applay-ing the function par which returns the list of parameterscorresponding to a specific identifier (id). The insertSboinsert a new component in a library by concatenating(at the end of the list) the existing library with the newelement (++).

The Undesired Event (UE)

An undesired event (UE) is defined by some safety prop-erties. It is specified as the last event in a chain ofevents with devastating impact on one or more individ-uals, ecosystems or materials. It is strongly correlatedto the thermal conditions, the amount of toxic gases and

smokes, and the pressure in a local. It is considered as


7/9

an extreme condition. An UE can be the reaching of acertain temperature in the upper layer (TU) of a local(gas temperature), a certain height of the smoke or theachievement of a critical pressure.Based on their experience, fire engineer define manuallyundesired events (with simple conditions). The evalua-

tion of fire safety level is highly correlated with the fre-quency occurrence of the undesired events (UE) whichreflects conditions leading to the death of a person ordestruction of material. Some examples of undesiredevents are:

room == 2 && TU > 550

room == 1 && teta < 350 && P > 100room == 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 beendefined as a list ([]) as follow:

data UE = UE[(Params)]

data Params = Par[(Op, Factor, Factor)]data Op = Inf String | Sup String

| Equ String | Amp Paramsdata Factor = Id String | Val Float | Room Int

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, Supor Amp) to model the room identifier (Int), compar-ison between physical quantities (String) and values(Float) (Inf String or Sup String) and/or to com-pose them with a conjunction (Amp Params) in the sameroom. In Haskell, the data type UE can also be defined

using its constructors. The result of the simulator isused to define a context function to get the value of aparticular symbol.

type Time = Integer

type Context = (Time, String) -> Float

The set of sorts used to specify an undesired event is:S = {UE , P arams, Op,F actor, T ime, Context}. Util-ity functions are defined to manipulate the data typeUE. The function parseUE is a specific parser thattransforms a string to an UE sort. The function evalis defined to evaluate an event in a context and ata precise instant and insert is defined to add a new

undesired event in the UE list. Quantity and localfunctions extract specific information from the unde-sired events list, respectively list of parameters in aspecific room and rooms in which we want to verify ifthe undesired event happened or not [Int]. The list ofthese functions constitutes the operations of the alge-bra: S = {parseU E, eval, insert, quantity, local}. Thedefinition of these functions which defines the relationspart of the algebra is given by:

parseUE :: String -> UE

eval :: (UE, Context, Time) -> Bool

insert :: (Time, Factor, Factor, UE) -> UEquantity :: (UE, Int) -> [Params]

local :: UE -> [int]

To manipulate an undesired event, the description ofutility functions behavior is given by the following equa-tions:

insert [] = []

insert ev (o,s,v)= ev++[(o,s,v)]

quantity [] = []

quantity u i = 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 atriplet in a list returns a list composed with concatena-tion (++) of the new element and list elements. Quan-tity returns the list of parameters to be checkes in aspecific room. the function locar returns the list of all

locals in undesired events. Finally the parseUE func-tion is used with the eval function to get the checkercomponent: checker= evalparseU E

Simulation

The specific datatypes presented above and abstractingdifferent models needed to describe the fire evaluationsafety system and merged into a simulation. This lat-est represent the base of a configuration. It containsthe same kind of information as a configuration, andincludes references to architectural model, library and

the definition of undesired events too. An example of asimulation is:

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

SBO=sbo.data MAX_CONFIGURATION=8 ATOL=1.D-9DTETA=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 grammar of a configuration has been extended tointegrate the other models; we call it simulation. Firstit refers the models presented above as for instancethe PLAN, the libraries and informs how many con-figuration to be generated in the bloc MISC and thenthe fire places and undesired events. The link betweenthe property and the architectural model is made bya property called GEO. The libraries are integrated

as entire blocs in the simulation. The simulation is


8/9

coded and attached to a datatype Simu, which is ab-stracted by a list of a string for the component identi-fier (e.g. MISC, LOC,OUV), and a list of properties.Each property is made by a couple of property identi-fiers abstracted by a string (e.g. ID, PLAN, GEO) andthe value of that identifier. The formalization of the

datatype Simu leads to the set of sorts S specifying asimulationS= {Simu,P rop,V alue}. The definition ofa simulation is coded with Haskell as follow:

data Simu = Simu[(String, [Prop])]

data Prop = Prop(String, Value)

data Value = V String | IS Float | I Int

A parser is defined to translate a string to aSimu datatype: parseSimu :: String Simuand an unparser to rewrite a Simu in another for-mat unparseSimu :: Simu String. Someother functions are defined to manipulate thedatatype what defines the list of operations O =

{parseSimu, unparseSimu, get, elements}. The func-tion getreturns a list of properties attached to a com-ponent in a simulation get :: (Simu,S tring) [Prop]and elementsreturns the list of components of a simu-lation elements :: Simu [String]. To manipulate asimulation, the description of utility functions behavioris given by the following equations:

get [] = []

get Simu(a,p) s = map (snd(s,p) where snd(a,x:xs)=xs)elements [] = []

elements Simu(a,p)= 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 thefunction snd, and the function Haskell map apply thelatest function on all simulation elements. The sameprocess to define the function elements, but we extractthe first elements (using the function fst) of pairs makinga simulation.

Intervals

In order to make random selections of values, an intervallanguage is defined. An interval substitutes a simplevalue 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 areenumeration of simple values: either string or numbers.Concepts of this language are coded and attached to adatatype 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 withas parameters a list of a strings (IV[String]) to enu-merate the values of the interval, a triplet of floats(IS(F loat, F loat, F loat)) referring to the initial, finaland step values or just a string (V String) or a float(V Float).

Global integration

A configuration needs many models (architectural,fireplace, construction materials and undesiredevents) to be made. Each one is abstracted by adatatype, and transformed to be complaint withthe simulation (using unparse functions). Lets de-fine 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 asimulation are IFC, MAT, SBO, undesired eventsand the interval, the destination is a simulation

(T : (Archi,MAT,SBO,UE,Inter) Simu). Thesimulation refers transformed models basing on theirspecific datatypes and making a composition of theselatter, what leads to T(Ifc,Lib,UE,Inter)=T(If c)T(Lib) T(U E) T(Inter). All values in it can beintervals, what allows to take randomly several valuesto make many configuration.

Based on datatypes and their specific functions, the sim-ulation extracts data necessary to make a configuration(e.g. the architecture of the locals and openings). Somemanipulation functions are defined as for instance the

function read which reads the content of the externalfiles 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 spe-cific languages is made by referencing components inthe other models (external files), getters of the specificdatatypes select and extract these components. Thesimulation is then sent to the generator which get ran-domly a value in each interval to make a configurationand then replace the references by the values extracted.These steps are repeated many times to produce severalconfigurations (input to the fire simulator). The follow-ing code reads the external files, then transforms theircontents in specific types (Ifc, Mat, ...), and generatesan initial state (ctx[0]). By applying this initial stateon the architectural and fire models, it calculates a newstate and save it in result file. This step is repeatedmany 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")


9/9

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 thequantities calculated by the model for example the tem-perature in upper layer. The evolution state of the sys-tem is saved in result- files. The config- files containthe different configurations generated by the generator.The result- and config- files, joined to the definitionof the undesired events are sent to the checker to verifyif the undesired events have been reached or not. Theresults of checking and the fire safety level are corre-lated to the occurrence frequency of the UE. The safetylevel is at least quantified by calculating the achievementrate of UE based on the total number of configurations(MAX CONFIGURATION). The aim of evaluatingfire safety level in building is to protect human lives inthe case of a fire. In fire situation unexpected conditions

affect fire behavior as for instance the reaction of a hu-man in in a fire room (e.g. human movement betweenrooms or opening doors and windows). In this case theSBO bloc will have several behaviors depending on timeand conditions. At the moment these cases are not con-sidered to make a configuration, but the next step of thiswork is to integrate the human behavior in the evalu-ation process. In this case a human specific languagemust be defined and integrated to the simulation.

CONCLUSION

In order to integrate the different models and specificlanguages required in the field of fire safety on a uniqueplatform, this paper proposed algebra and functionalprogramming. Concepts of algebra allow the definitionof higher level function for transformation, integrationand composition of several models that do not necessar-ily use the same language. The abstract syntax and aconcrete syntax of the specific languages are described.The simulation language which integrates all of theminto one comprehensive set is described too. Evaluationof a fire safety level requires a lot of configurations tostudy. To generate them randomly, an interval languageextension is combined with all of the previous languages.The expected tool is now able to study building, and thenext step will be to introduce a new DSL about humanbehaviors.

REFERENCES

Biggerstaff T., 1998. A perspective of generative reuse.Annals of Software Engineering, 5, no. 1, 169226.ISSN 1022-7091, 1573-7489.

Bodart X. and Curtat M., 1987. CIFI Computer Code:Air and Smoke Movement During a Fire in a Build-

ing With Ventilation Ducts Networks Equipment. CIB

Publication - Workshop on Fire Modeling - Berlin,West Germany, vol. 104.

Fokkinga M., 1992. A Gentle Introduction to CategoryTheory - the calculational approach. InLecture Notesof the STOP 1992 S ummerschool on ConstructiveAlgorithmics, University of Utrecht. 172 of Part 1.

Fowler M., 2010. Domain-Specific Languages. PearsonEducation. ISBN 9780131392809.

Goguen J.A. and Malcolm G., 1996. Algebraic Seman-tics of Imperative Programs. MIT Press, Cambridge,MA, USA.

Habrias H. and Frappier M., 2006. Software Specifica-tion 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 spreadand carbon monoxide transportation in a long chan-

nel: Fire Dynamics Simulator comparisons with mea-sured data. Journal of Hazardous Materials, 140, no.12, 293298. ISSN 0304-3894.

Hutton G., 1998. Fold and Unfold for Program Seman-tics. In In Proc. 3rd ACM SIGPLAN InternationalConference on Functional Programming. ACM Press,280288.

Hutton G. and Meijer E., 1998. Monadic parsing inHaskell. 8, no. 4, 437444.

Martens B. and Herbert P., 2004. ArchiCAD. Springer.ISBN 9783211407554.

Meijer E.; Fokkinga M.; and Paterson R., 1991. Func-tional Programming with Bananas, Lenses, Envelopesand Barbed Wire. Springer-Verlag, 124144.

OSullivan B.; Goerzen J.; and Stewart D., 2008. RealWorld Haskell. OReilly Media, Inc., 1st ed.

Parry R.; Wade C.A.; and Spearpoint M., 2003. Imple-menting a Glass Fracture Module in the BRANZFIREZone 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 ModelsUsing Maude. 85, no. 11, 778792. ISSN 0037-5497,1741-3133.

Russell J. and Cohn R., 2012. Haskell (programmingLanguage). Book on Demand. ISBN 9785510997262.

Spearpoint M.J., 2006. Fire engineering propertiesin the IFC building product model and mapping toBRANZFIRE. International Journal on EngineeringPerformance-Based Fire Codes, 134147.

Van Deursen A.; Klint P.; and Visser J., 2000. Domain-Specific Languages: an annotated bibliography. SIG-

PLAN Not, 35, no. 6, 2636. ISSN 0362-1340.

Documents

Algebra Applied to the Multimodeling of Fire Protection Systems