5(9,67$ 520Â1 `( $8720$7,&amp

Transcription

Â
June 2008
Volume XXI
Number 2
ISSN 1454-9077
DISTRIBUTED, REALTIME PROGRAMMING BASED ON A FORMAL SEMANTICS ON
COMMODITY POSIX SYSTEMS WITH NO INKERNEL REALTIME SUPPORT…………. 1
……………………………………Stefan D. Bruda, Petter Haggholm, Scott Stoddard, Rob Britton
INTELLIGENT STORE - AN INNOVATIVE TECHNOLOGICAL SOLUTION FOR
RETAIL ACTIVITIES…………………………………………………………………………. 12
Carmen E. Stan, Dan Dumitrescu, Vasilica Caras, Doru E. Tiliute, Eugen Pop Lucian E. Anghel
AUTOMATIC SYSTEM FOR OPTIMIZATION OF OPERATION OF A GAS
COGENERATION POWER PLANT……………………………………...……………………….. 19
…………………………………………………………………………………………………..…Ion Miciu
SINTESERV – AN INFORMATION SYSTEM READY TO ENHANCE THE RELATIONSHIP
BETWEEN LOCAL AUTHORITIES, CITIZEN AND BUSINESS ENVIRONMENT............. 27
..................Alexandru Botu, Adrian Badoiu, Sanda Petrescu, Vasilica Vlad, Gheorghe Matei
FLOOD RISK REDUCTION SOLUTIONS IN PLACES LOCATED NEAR URBAN AREAS..32
…………………………….Carmen Eleonora Stan, Andrei Iancu, Dan Dumitrescu, Virgil Olaru,
Dan Marinovici, Daniela Zvorăúteanu, Gabriel RacoviĠeanu, Gabriel Tatu, Sorin Dinea
WEB-BASED MEDIATION SYSTEM FOR POORLY DEVELOPED ECONOMIC AREAS.. 40
………………Alexandru Botu, Adrian Badoiu, Sanda Petrescu, Vasilica Vlad, Gheorghe Matei
MANAGEMENT AND CONTROL OF PRODUCTION AND LOGISTICS MCPL
IFAC CONFERENCE (4TH) ………………………………………………………………….... 45
Sibiu, Romania, 27 – 30 September, 2007
eHYDROGENIA © H2_FUEL_CELLS_MILLENIUM_CONVERGENCE................................ 46
September 22-23, 2008, Bucharest, Romania
9-th EUROPEAN CONFERENCE on E-BUSINESS/E-COMMERCE/ E-LEARNING/
E-WORK/ E-GOVERNMENT/ E-DEMOCRACY/ E-HEALTH/ E-MEDIARY, E-INCLUSION /
BB-BROAD-BAND, ON-LINE SERVICES / E-MARINE / E-BANKING, ADAPTNETICS,
AND THEIR INFLUENCES ON THE ECONOMIC/ SOCIAL ENVIRONMENT
AND CONTRIBUTIONS TO ERA E-COMM-LINE 2008……………………………………... 50
September 25-26, 2008, Bucharest, Romania
Printed with the support of the Romanian Education and Research Ministry
1-1
RRA, Vol. XXI, Nr. 2, pag. 1–11, 2008
Printed in Romania
Distributed, Real-Time Programming Based on a Formal Semantics on Commodity
POSIX Systems with no In-Kernel Real-Time Support∗
Stefan D. BRUDA, Petter HÄGGHOLM, Scott STODDARD, and Rob BRITTON
Department of Computer Science, Bishop’s University
2600 College St, Sherbrooke, Quebec J1M 1Z7, Canada
{bruda,petter,scott,rob}@cs.ubishops.ca
Abstract: We present an implementation of a programming language that allows programming of real-time
applications distributed over a network. We have several goals in mind: First, the language should be built on a
sound semantics and offer support for model-based conformance testing. At the same time the language should
place the normal programmer (who tends to shy away from exceedingly formal constructs) in a comfortable
environment. Thirdly, programs written in this language should run on commodity systems, without relying
on real-time support from the kernel. Finally, the language separates the code from timing restrictions, thus
allowing for code re-use.
Keywords: real time, distributed programming, model-based conformance testing, actors, POSIX
1
Introduction
Both the functional and the temporal behaviour are
essential in real-time systems; correctness depends
not only on the result of computations, but also on
the time at which the results are produced. Building such systems has become increasingly difficult
due to their use in larger and more complex applications. This increased complexity coupled with sophisticated demands in terms of safety and performance have generated increased interest in methodologies and tools that make the analysis and modelling of real-time systems possible in terms of executable models.
Classical real-time programming languages allow the specification of time constraints along with
the code being executed; the code then is restricted
to run within the associated timing constraints. Examples include MPL [11] and RTC++ [9]. Timing restriction re-usability (which is absent from the
mentioned languages) is introduced in an object oriented environment by HRTC++ [13], and can be further enhanced by introducing new constructs such as
temporal abstract classes [12].
Languages like the ones mentioned above aim
at easing the development and maintenance process
∗
This research was supported by the Natural Sciences
and Engineering Research Council of Canada, by the Fond
québécois de recherche sur la nature et les technologies, and
in part by Bishop’s University.
of systems by encapsulating timing information into
the objects; although certainly possible within the
underlying (non-real-time) language, the development of distributed systems is not consciously considered. However, distributed systems (more generally, concurrent systems) are becoming popular
at a tremendous rate. Languages such as DROL
[20] address the distributed nature of systems explicitly. DROL is (once more) an extension of C++ that
describes on a meta-level the semantics of (asynchronous) message passing, including timing constraints (embedded in the objects that communicate with each other). DROL is implemented on a
specialized, real-time kernel. Another—and probably the most popular—facilitator of distributed,
real-time programming is MPI/RT [19], a de-facto
standard that provides a portable API for real-time
message passing and synchronization (while being silent in the area of process/thread scheduling).
MPI/RT addresses re-usability issues by emphasizing an object-oriented design for the API.
A different approach is taken in the modelling
language ROOM [17], which is based on establishing early operational models and then refining them
to implementation. System modelling with ROOM
is performed by designing actors communicating
via point-to-point links by sending and receiving
messages. The behavior of an actor is represented by
an extended state machine. Incoming messages trigger transitions associated with the actor’s state ma-
2
chine. ROOM does not constrain the actors; instead,
annotations to the message sequence charts can be
used to indicate timing constraints, and constraints
such as deadlines and periodicity are specified on
end-to-end computations.
The particular way ROOM imposes timing constraints is worth noting as being opposed to the other
programming languages. We believe that imposing
end-to-end constraints is the logical way to go, for
indeed timing constraints represent global, application level properties. When using a real-time language such as HRTC++ or an API like MPI/RT one
must perform an extra step to infer the local constraints expressible by the language from the global
constraints included in the specification.
A semantics of communication similar to
ROOM’s is also possible in a more general setting
[10]: An RT-Synchronizers− system is defined as
a collection of “active objects” that executes concurrently, communicating via messages; timing constraints are imposed on the messages. In this model,
the functionality of objects can be implemented
using a general purpose language (as opposed to
ROOM’s restricted model), and then the objects are
glued together by interaction constraints. The constraints are established on top of ordinary objects.
The RT-Synchronizers− semantics contains no reference to end-to-end (or global) timing constraints,
though they are implicitly supported.
We also note that ROOM—as opposed to the
languages presented before—is a modelling rather
than a general purpose language, so the language is
based on formal models. Many other similar languages exist [15], along with languages based on
process algebrae such as CSP [16] or their underlying semantics of labelled transition systems [8].
This kind of languages are preferred because of their
suitability for formal model checking and conformance testing. On the other hand—at least in our
experience—they place the average computer science graduates (that is, the bulk of future programmers) in an unfamiliar territory; the bulk of programmers are not at ease in other environments than the
one of imperative languages.
In all, many fine general purpose, real-time programming languages exist; they offer in varying degrees a separation between timing constraints and
functional behaviour, and some are probably implementable without real-time support from the kernel
(though we are not aware of any significant approach
on the matter). None of these languages however
offer support for model-based conformance testing.
REVISTA ROMÂNĂ DE AUTOMATICĂ
The modelling language ROOM (and other modelling languages) on the other hand does offer such
support, but its underlying functionality is given in
terms of finite state automata, which are neither general nor a familiar territory for the usual programmer. We address in what follows the issue of realtime programming by developping a new programming language that combines the features found in
the two categories mentioned above.
We are primarily interested in offering a good
foundation for model-based testing, but we also consider in the process the following characteristics (encountered in the languages presented above, though
not necessarily together): a real-time system constructed using our programming language consists
of a number of modules which are programmed in
a general purpose programming language. The general purpose language itself is however immaterial
to the specification of timing constraints, which are
instead imposed on the inter-module communication
using constructs that are independent of the communicating modules. We aim for a separation between
functional behaviour and timing constraints, which
is natural for real-time specifications. In the process, we thus promote a component-oriented programming [6] style. Indeed, since modules themselves have nothing to do with real time, they can be
changed and re-used at will, in a normal fashion.
The basis of real-time application specifications
is global (or end-to-end) timing constraints, so our
language supports this kind of constraints. Recognizing that local constraints are potentially useful
(even if not part of the specification), we also allow
for the specification of point-to-point constraints.
Initiating the transmission of inter-module messages
is as much as possible transparent; a module issues
a “method call” to another module in the same way
as it issues a call to a local method.
Building distributed systems is a central concern in designing the language. Many modules can
be grouped into a process (or “node”), and many
processes communicate to each other using internet
sockets.
Finally, a program written using our programming language runs on commodity, POSIXcompliant operating systems. In particular it does
not rely on real-time support from the underlying
OS.
We offer a semantics for such a system in Section 2. We then offer in Section 3 an overview and
also a small programmer’s guide of the resulting RTS YNC programming language. Section 4 presents
the internal of the system (from the developer’s point
of view). Conclsions and future developments follow in Section 5.
2
Semantics
Our implementation follows a semantics based on
the semantics of RT-Synchronizers− [10] which is
in turn based on the actor model [1]: distributed entities are modelled as self-contained objects called
actors. An actor encapsulate a state, provides a set
of public methods, and may call methods from other
objects by means of message passing. Actors thus
represent the layer of an RTS YNC program that executes the code specified by the user which (generally) interacts with the outside world. The actors
execute concurrently, and are identified by unique
names (sometimes “mail addresses”). The original message passing scheme is non-blocking and
buffered, meaning that an actor resumes normal operation immediately after sending a message without waiting for a reply from the receiver, and that
messages sent but not yet processed by the receiver
are buffered until the receiver accepts them. Recognizing the however rare need for synchronization
between actors, we also offer a blocking message
passing scheme (introduced in the syntax by the
sync snd construct).
To send a message an actor calls a method of
some other actor; a message d.m(p) contains the
name d of the destination actor, the name m of the
method to be invoked at the destination, and possibly a set p of parameters to be passed to the method
being called. For the blocking case the message
needs to contain the name of the sender (though this
needs not be specified explicitly by the programmer). We end up with an implementation syntax
similar to the one noted above, but we use the notation ha ⇐ a0 , cvi in our semantical description,
where a represents the destination of the message,
a0 the sender (or λ for non-blocking messages), and
cv is the body of the message which includes the
name of the method to be invoked at the destination
and also the parameters (the existence of a method
name and parameters is immaterial for the message
passing mechanism).
With this structure for messages, the semantics of actors is given by the transition system −→κ
shown in Figure 1. The state of a set of actors is
modeled as a pair hhα|µii, with α and µ representing
the actor state and the set of pending messages, respectively. The state of an actor a is written [E ` b]a
3
with E the environment and b the remainder of the
actor behaviour. The actor reduces its behaviour until it reaches ready(x); this signifies that actor a is
waiting for a message (whose content is then bound
to x). The transition system −→λ defines the semantics of the programming language used to program
actor behaviour. The environment variables wa are
fresh variables initialized with the special value λ;
they hold the sender of the last blocking message (in
order to send an acknowledgment when the called
method completed), or λ whenever the last message
was non-blocking.
We note that one cannot make timing assertions
about the execution of an actor program directly. In
order to make this observation explicit the delay actions ε(d) is introduced, with d a positive number
representing the passage of d time units. The actor
evolves by performing a sequence of instantaneous
actions and by letting the time pass.
Messages are intercepted by synchronizers.
They are reactive agents that exist to monitor and
enforce time constraints upon the inter-actor message communication. Every actor-actor relation (a
relation between actors a and b exists whenever a
references a method of b, or vice-versa) may have
an associated (“coordinating”) synchronizer. This
synchronizer then intercepts all communication between the two actors and enforces user-defined timing constraints expressed as real-time constraints on
pairs of message invocations.
The semantics of one constraint in a synchronizer is given by the transition system −→γ shown
in Figure 2. The state variables of a synchronizer
are represented by an environment V that maps variables to their values. A constraint can have two
forms: p1 =⇒ p2 ∼ y, ∼∈ {≺, }, where p1 , p2
are message patterns, and y is a positive, real valued
variable or constant; the first form specifies that a
message matching the pattern p2 must follow a message matching p1 no later than y time units. Conversely, the second form specifies that y time units
must pass after a message matching p1 occurs before
a message matching p2 is allowed. Whenever an
invocation matches p1 the constraint fires and thus
creates a new demand instance matching p2 . Such
a demand is represented by a triple p2 ∼ d, with
d (a real number) denoting the deadline or release
time of p2 . The state of a constraint is represented
as a constraint configuration h|χ|ξ∼ |i; ξ∼ is a static
description of a constraint p1 =⇒ p2 ∼ y and χ is
a multi-set of demands instantiated from this static
description.
4
hfun : ai
E ` b −→λ E 0 ` b0
hhα, [E ` b]a |µii −→κ hhα, [E 0 ` b0 ]a |µii
hsnd : a, ha0 ⇐ λ, cvii
hhα, [E ` send(a0 , cv); b]a |µii −→κ hhα, [E ` b]a |µ; ha0 ⇐ λ, cviii
hsync snd : a, ha0 ⇐ a, cvii
hhα, [E ` sync send(a0 , cv); b]a |µii −→κ hhα, [E ` wait(a0 ); b]a |µ; ha0 ⇐ a, cviii
hwait : a, a0 i
hhα, [E ` wait(a0 ); b]a |µ; ack(a)ii −→κ hhα, [E ` b]a |µii
hrcv : a, ha ⇐ a0 , cvii
E(wa ) 6= λ
hhα, [E ` ready(x); b]a |µ; ha ⇐
−→κ hhα, [E[x 7→ cv, wa →
7 a0 ] ` b]a |µ; ack(E(wa ))ii
E(wa ) = λ
0
hhα, [E ` ready(x); b]a |µ; ha ⇐ a , cviii −→κ hhα, [E[x 7→ cv, wa →
7 a0 ] ` b]a |µii
hdelay : di
a0 , cviii
ε(d)
hhα|µii −→κ hhα|µii
Figure 1: Actor configuration transitions.
The passage of time is controlled by the Delay
rule. The elapsed time e is subtracted from di in
each demand pi ∼ di ; this is written χ e. The delay rule ensures that deadline constraints are always
satisfied.
A synchronizer is then represented by a synchronizer configuration hγ|V i where γ is a set of
constraint configurations ranged over by γi and V
represent the state variables of a synchronizer by
means of a mapping from identifiers to their values.
The semantics of a synchronizer is shown in Figure 3. Triggers can be attached to events, and their
effect (not shown in the figure but rather trivial to
consider) is to transform V according to the assignments specified therein.
For convenience we differentiate between pointto-point synchronizers (just synchronizers for short)
and global synchronizers. The global synchronizers
impose general (and not only point-to-point) constraints.
hAction : li
l
∀i ∈ [1 . . . n], γi −→γ γi0
,
l
h|γ1 , . . . , γn |V |i −→σ h|γ10 , . . . , γn0 |V 0 |i
l ∈ {ha ⇐ a0 , cvi, ε(e), ack(a)}
Figure 3: Synchronizer semantics.
Constraining an actor program is defined as a
special form of parallel composition k. An interaction constraint system configuration is written as
((σ1 , . . . , σn )), where σ ranges over synchronizer
configurations. The composition of an actor configuration and an interaction constraint system is defined by the transition system −→κσ shown in Figure 4.
3
The RTS YNC system
An RTS YNC (distributed) program consists in a set
of RTS YNC nodes. A node is a standalone executable that can work in isolation or communicate with other nodes through internet domain sockets. Each node contains a number of actors (which
perform non-constrained actions) and synchronizers
(which enforce timing constraints over inter-actor
communication). Both the inter-node communication and the intra-node message passing is coordinated by postmasters. Each RTS YNC node runs exactly one such a postmaster.
RTS YNC nodes are C++ programs that contain blocks of RTS YNC specific code. The RTS YNC compiler takes source programs in this format, parses the RTS YNC specific-code, and so generates C++ code which it outputs along with the surrounding C++ code. This resultant code file can then
be compiled with a C++ compiler to produce an executable. During compilation a run time library must
5
hSat≺ : ha ⇐ a0 , cvii
∅
if ha ⇐ a0 , cvi p2
p2 ≺ V (y) if ha ⇐ a0 , cvi p1
=
c
cs =
f
0
∅
otherwise
p2 ≺ d otherwise
U
U
U
ha⇐a0 ,cvi
h|χ p2 ≺ d0 |ξ≺ |i −→γ h|χ cf cs |ξ≺ |i
0
hSat : ha ⇐ a , cvii
p2 V (y) if ha ⇐ a0 , cvi p1
∅
if ha ⇐ a0 , cvi p2 ∧ d0 ≤ 0
cs =
c
=
f
0
∅
otherwise
p2 ≺ d otherwise
U
U
U
ha⇐a0 ,cvi
h|χ p2 d0 |ξ |i −→γ h|χ cf cs |ξ≺ |i
0
hSat∅ : ha ⇐ a , cvii
p2 ∼ V (y) if ha ⇐ a0 , cvi p1 , ∼∈ {≺, }
cf =
∅
otherwise
U
ha⇐a0 ,cvi
h|∅|ξ∼ |i −→γ h|∅ cf |ξ∼ |i
hAck : ack(a)i
ack(a)
∼∈ {≺, }
h|χ|ξ∼ |i −→γ h|χ|ξ∼ |i
hDelay∼ : ei
∼∈ {≺, }
ε(e)
∀p2 ≺ di ∈ (χ e), di ≥ 0 : h|χ|ξ∼ |i −→γ h|χ e|ξ∼ |i
def
Figure 2: Single constraint semantics; ha ⇐ a0 , cvi x1 (x2 ) when b = a = V (x1 ) ∧ b(V [x2 7→ cv])
be linked in. The library contains all of the run-time
code needed by the program (parent classes, postmaster code, logging, etc.).
Our programming language produces code that
does not require real-time resources from the operating system. Indeed, about the only requirements
are a POSIX-compliant operating system, an ANSI
C++ compiler, and the potable BOOST libraries [2].
The distributed nature of the system is very flexible, being implemented in a “peer to peer” fashion. No centralized control exists, and individual
“nodes” are free to enter and leave the network at
any time.
Timing violations are of course always detected
at run time. Once such a violation is detected a handling routine is run. The programmer has the option of defining such a handler for each synchronizer; upon completion the handler may optionally
terminate the current node or the whole system.
Static timing analysis (and in general conformance testing) is more useful than run-time detection and is our main, active research interest. At
this time static analysis produces a timed call graph
for method calls and then computes its reflexive and
transitive closure in order to take global constraints
into consideration. The process is restricted to constant time restrictions, and does not take into consideration the running time of unrestricted code inside
actors. It is also a somehow ad-hoc process, having
the role of a stub for future development rather than
being a good implementation.
3.1 Actors
Actors are the active agents of the system: they execute code and generate messages for communication
(“method calls”); the other RTS YNC entities merely
serve as support and co-ordination. Messages are
thus formed and eventually decoded and acted upon
solely at the actor level (a message is generated
whenever a “method call” referencing a method of
a foreign actor is performed within an actor). Note
that since messages only occur in inter-actor communication, and since only messages are subject to
time constraints, activities occurring within an actor
cannot be time constrained.
An actor is defined in RTS YNC as a block
whose structure is shown in Figure 5. An actor is
identified by its name specified after the actor keyword. It contains a set of declarations for the local
variables, followed by a series of blocks of code.
The first such a block (the initialization code, introduced by the keyword init) is executed when the
system starts up. The next blocks of code are methods triggered by incoming messages. Such blocks
are introduced by the name of the method, followed
by a list of formal parameters, followed by an arbitrary block of code that implements the respective
method.
Actors are written in a general purpose language
such as C. In the current, proof of concept implementation we use a subset of C dubbed C-. The language (described by a rather readable YACC source)
6
Untimed actions
l
hhα|µii −→κ hhα0 |µ0 ii
∈ {
l
hfun : ai, hsnd : a, mi, hsync snd : a, mi,
hwait : a, a0 i, hready : ai }
l
hhα|µiik((σ1 , . . . , σn )) −→κσ hhα0 |µ0 iik((σ1 , . . . , σn ))
Receive
l
hhα|µii −→κ hhα0 |µ0 ii
V
i∈[1...n]
σi
ha⇐a0 ,cvi
−→γ
σi0
l = {hrcv : a, ha ⇐ a0 , cvii}
l
hhα|µiik((σ1 , . . . , σn )) −→κσ hhα0 |µ0 iik((σ10 , . . . , σn0 ))
Synchronization
V
i∈[1...n] σi
ack(a)
−→γ σi0
ack(a)
Delay
V
ε(d)
0
i∈[1...n] σi −→γ σi
ε(d)
Figure 4: Combined semantics of the system.
actor name {
C- variable declarations
init { C- code }
method-name (parameters) { C- code }
method-name (parameters) { C- code }
...
}
Figure 5: The structure of an actor block.
is immaterial to the functionality of the system, and
it can be easily enhanced (or even changed altogether).
One special statement of the language is the one
that implements the call of a method (of another actor). This syntax of such a statement is a.m(p), with
a the name of the actor whose method m is to be
executed with p as list of arguments. Once the statement is executed a message is sent to actor a. Such a
message is intercepted and processed by a synchronizer, so the actual message passing mechanism is
described in the next section.
The default non-blocking semantics can be
changed by prefixing the method call with the keyword sync. In such a case the caller blocks until the
callee completes the execution of the method specified by the message.
3.2 Synchronizers
The syntax of a synchronizer is shown in Figure 6. A
synchronizer consists in four parts: a set of instantiation parameters, instantiation code, and declaration
of local variables; a set of constraints; a set of triggers; and an exception handler. Messages of interest
are identified by patterns, which have in the current
implementation the form a.m where a specifies the
destination actor and m is the name of the method to
be called as a consequence of the message.
As for the actors, the initialization code is introduced by the keyword init. Unlike the actors, the
init keyword is followed by a construct of the form (
actor1<->actor2) ). This construct specifies that the
current synchronizer intercepts messages exchanged
between actors actor1 and actor2.
Only one synchronizer may be the designated
coordinator of any given actor pair, and the relation
is commutative. The presence of an explicitly defined synchronizer at any such relation is optional;
relationships may be unconstrained, in which case
the system automatically provides a null synchronizer; no assertions regarding timing can be made
in such a case.
Recall that a constraint can have two forms:
p1 =⇒ p2 ≺ y and p1 =⇒ p2 y, where p1 , p2
are message patterns, and y is a positive, real valued
variable or constant. These two forms are introduced
in the current implementation by the keywords min
and max, respectively. A message intercepted by the
synchronizer is continuously “polled.” The synchronizer examines the message’s time constraints to determine whether the message is a valid candidate for
execution (i.e., the minimum time before execution
has passed) and whether the message has violated
any constraints (i.e. whether its “must run before”
synchronizer name {
C- variable declarations
init ( actor1<->actor2) ) { C- code }
constraint {
min actor.method -> actor’.method’ = expr ;
max actor.method -> actor’.method’ = expr ;
...
}
trigger {
enable ( actor.method ) when expr ;
disable ( actor.method ) when expr ;
action ( actor.method ) { C- code }
...
}
exception { C- code with return statement }
}
Figure 6: Structure for a synchronizer block.
time has passed), and taking the proper action. In
the first case, the synchronizer holds a message until
it is a valid candidate for execution, at which point
the synchronizer relays it to its proper destination.
In the case of a message violating timing constraints,
the synchronizer throws an exception and drops the
message (which is thus never delivered).
Once the timing constraints managed by the
synchronizer are violated, the code from the exception section is called. This is the only section in
which the return keyword is allowed, with the argument TERMINATE (with the effect that the whole
RTS YNC system is terminated), KILLNODE (with
the effect that the current node is terminated), or
CONTINUE (which specifies that the exception has
been taken care of and execution can continue).
Synchronizers may also perform noncoordinating tasks by responding to arbitrary
events (“events” being specific methods calls) by
means of triggers. These can be action triggers,
which are arbitrary code blocks executed upon
notification of certain events, or enable/disable
triggers, which globally enable or disable individual
methods of actors subsequent to particular events.
Global synchronizers In addition to the pointto-point timing constraints specified by the RTSynchronizers− [10] semantics (and implemented
by synchronizers), ROOM’s transaction constraints
(also referred to as “global constraints” [10]) are
implemented by global synchronizers. The syntax of global synchronizers is similar to the syntax of (point-to-point) synchronizers (shown in Figure 6), except that they are introduced by the keyword global rather than synchronizer.
7
Transaction constraints must be synchronized
by the global synchronizer. Any constraint expression over relations that are not point-to-point in
terms of method calls, although syntactically valid,
are not allowed in normal synchronizers; synchronizers are validated against the timed call graph.
4
RTS YNC internals
The following is a brief summary of the internal
structure of the RTS YNC system. It includes more
detailed discusions about particular components of
the system that are not straightforward and are not
described earlier. For a complete picture, this section should be read in conjunction with the the complete API documentation available on the RTS YNC
Web page [14].
4.1 Actors
Every actor in the system inherits from the actor
class and for the purpose of the modular scheduler
also inherits from schedulable. The parent actor
class defines the necessary functions such that every actor can setup a polling thread after construction. The purpose of an actor’s polling thread is to
request messages from synchronizers (whenever it
has message registrations in m_msg_requests) and
to execute the methods contained in those messages.
Note that execution is done in the polling thread and
therefore only one message is acted upon at a time.
In a system such as ours dynamic priority for
the participating threads (assigned according to the
priorities of the pending messages) is imperative.
Scheduling threads for execution according to their
priorities is accomplished by a system that blocks
all but the highest priority threads; the unblocked
threads run then concurrently being scheduled on the
processor(s) according to the (non real time) kernel
scheduler. Message queues are implemented on a
per-thread basis. Message priorities (which in turn
determine thread priorities) are assigned dynamically, based on their time constraints.
In essence our implementation is based on the
generalized rate-monotonic scheduling theory [18],
under which all the tasks meet their deadlines as
long as the system load lies below a certain bound.
Given the assumed lack of real-time support from
the kernel (and the limited actual support currently
available on real-time systems) this mechanism is
implemented using signals. Specifically, all but the
highest priority threads are blocked waiting for a
critical region within the handler of a specific signal.
8
The scheduler then unblocks lower priority threads
whenever the highest priotiry threads complete. This
mechanism implies a certain time coarseness; however, the coarseness is similar to the one induced by
the network communication stack so we do not consider it a serious limitation.
4.3 Messages in an RTS YNC system
Messages go through a (necessarily) complex handshake process as they travel through an RTS YNC
system. A message is thus subject to the following
process (controlled by postmasters) from inception
to destruction:
4.2 The postmaster
1. Message creation is done by source actor; creation timestamp is set.
The postmaster serves as the universal relay and dispatch engine for an RTS YNC system. All calls originating from actors or synchronizers route through
the postmaster so that the operation of actors and
synchronizers is fully network transparent. The
postmaster holds data structures that contain information about all RTS YNC entities within the local node, and essential information about all remote
nodes.
2. The message is then passed to coordinating
synchronizer by invoking sm_receive_msg of
the postmaster; the dispatch timestamp is set by
synchronizer when it receives the message.
Each node contains its own postmaster which
allows a distributed RTS YNC program to operate as
a peer-to-peer system. As such, there is no server,
rather clients fulfill both roles as needed throughout
the lifespan of the system. The general process is as
follows:
For a single node system (or the first node of a
distributed system), the node simply activates, sets
up a server port, and then goes about running (to the
extent that it can as it is waiting for other nodes).
For a node joining an already running system
the process is a little different. While it will still
set up a server port, it will (in the constructor) also
connect to the host that it has been provided with.
This initial interaction between client and “server”
serves to populate the new client with information
about all of the other nodes (postmasters) in the network. From there, the new client will initiate communication with each of the other nodes of the network to exchange information with them about their
respective setups. This is referred to as the population stage. Both client and server complete this
stage when they have each received a snapshot of the
other’s structure (members, methods, relationships,
etc.)
Once the (initial) population is complete, the
postmaster will continue execution of the run
method which is to say that it will either go into
an infinite poll loop or begin system execution by
passing an initial message. The network messaging
protocol uses a simple, plain-text, format for transmission.
3. The synchronizer holds the message in its incoming queue until time constraints allow for
its sending to the destination actor.
4. The message is then moved to outgoing queue
and the destination actor is notified that synchronizer has a message holding for it (via
am_register_msg).
5. When the actor’s polling thread is ready for this
message (all messages are received in order of
their timestamp), it calls sm_request_msg of
the postmaster; the return value of this call is
the message; the received timestamp is set upon
message arrival at the actor.
6. The actor executes the method specified by
the message using the parameters contained
within; execution timestamp is set when execution is complete.
7. The actor calls sm_ack_msg of the postmaster;
the result of this call is a passing of the message
to ack_msg of the synchronizer; this function’s
purpose is limited to status messages and to the
implementation of synchronous messages.
8. Actor notifies all of its registered listeners that
it completed execution of the method specified
by the message.
4.4 The network application protocol
The network messaging protocol uses a simple,
plain-text, format for transmission. The general format of a transmission packet consists of the following tokens: size of packet (excluding the size itself
and its trailing space), protocol directive (enumerated in postmaster.h), and optional parameters
(directive dependent).
9
• RT_POPULATION: response to a populate request (or send by new postmaster); parameters:
full population data from a node (see below).
A sample message is provided below. This message is of type RT_REQUEST and would be sent to a
node that contains a synchronizer named mysync.
After parsing, that synchronizer would be informed
that actor someactor would like a message from it.
• RT_TERMINATE: signal a postmaster sends to
other postmasters to tell them that it is going
to terminate; parameters: none.
18 3 mysync someactor
In general the system uses the following protocol directives:
• RT_KILLALL: once received by a postmaster, it
should immediately kill itself; the whole system is going down.
• RT_MESSAGE: normal RTS YNC message to be
acted upon (i.e. send to receiver); parameters:
the message.
• RT_TIMEUPDATE: notification that a method
has been run with new lastrun timestamp; parameters: actorref, method, rttime t.
• RT_NOTIF: notification of method completion
(send to listener); parameters: syncref, actorref, rttime t, method.
• RT_REQUEST: notifies a synchronizer that an
actor would like its next message; parameters:
syncref, actorref.
• RT_REQRESPONSE: reponse to an RT_REQUEST
(contains a message); parameters: the message.
• RT_SYNCNOTE: notification to actor locked in
synchronous call that remote party finished execution; parameters: message.
The following is the structure of a RT_POPULATION
packet (all tokens in each section are separated
by spaces, and all sections of the RT_POPULATION
packet are separated from previous sections by a dollar sign as shown):
• RT_REGMSG: notifies an actor that a message is
waiting; parameters: actorref, syncref, rttime t.
list of actors (local to the remote node) $
list of synchronizers (local to the remote
node) $ list of (2 actors, followed by a synchronizer (synchronizing pairs)) (global
synchronizer) $ list of (actor, method,
boolean enabled flag) (global list of all
methods in the system) $
• RT_ENABLE: enable an actor’s method; parameters: actorref, method.
• RT_DISABLE: disables an actor’s method; parameters: actorref, method.
• RT_REG_LISTENER: register synchronizer as
listener to actor; parameters: actorref, syncref.
• RT_RECVMSG: synchronizer received message;
parameters: syncref, message.
• RT_ACKMSG: acknowledge reception of message from synchronizer; parameters: syncref,
message.
• RT_POST_DISABLE: send notification to another postmaster that method was disabled; parameters: actorref, method.
• RT_POST_ENABLE: send notification to another
postmaster that method was enabled; parameters: actorref, method.
• RT_GET_NETIDS: request the list of net id-s
from another postmaster; parameters: none.
• RT_POPULATE: request a postmaster’s list of local actors and synchronizers; parameters: none.
5
Conclusions
Our primary goal was developing the RTS YNC system is to offer a general-purpose programming language that offers a good foundation for model-based
conformance testing of real-time, distributed systems. At the same time the language should also
place the normal programmer in a familiar environment, should produce code capable of running on
commodity systems, and should offer separation between time restrictions and code (thus facilitating
code re-use).
We described here an incipient implementation
of such a system. We have addressed the first three
goals by providing a familiar C-like language to the
programmer (still to be enhanced to a production
language) and by offering an implementation based
on dynamic priorities that should satisfy all the feasible real-time tasks. Our implementation uses internet domain sockets and is thus suitable for both
10
nodes distributed over a network and nodes running
concurrently on one machine; all the actors on one
machine are normally grouped into one node so that
they use shared memory to communicate instead of
sockets, but two or more nodes can run on the same
machine and communicate over the loopback subnet. Local subnet communication is important as
support for testing real-time systems, or to be more
precise for interfacing a running system with one or
more testing systems. Indeed, beside the usual input/output interface provided by the operating systems, a testing system is able to connect without recompilation to the system under test using the message passing interface already provided. A tester
would be thus able to test various time properties
(not necessarily limited to existent time constraints
since the tester could introduce more time restrictions of its own). We believe this to be a powerful
tool and so a significant contribution.
The system is also based on a sound semantical model. This offers a good starting point for our
most important goal, model-based testing. At this
time we offer some tools that could be used to accomplish this, but we fall short of actually performing any kind of formal testing. We base our implementation on a well defined semantics, so one would
be able to express the model semantically and then
derive both the test cases and the application itself
starting from the semantical model. Once this is accomplished, the actual conformance testing of the
end product is easily done as mentioned above.
At this time—i.e., without a proper formal
testing in place—our language should be regarded
as producing soft real-time systems; we intend to
strengthen the language so that it is able to produce
hard real-time systems at least for particular structures of such a system. Even so, the unpredictability
of network communication is expected to pose additional problems and needs further consideration.
We note finally the relation between our current work outlined here and timed ω-languages, the
previously developed complexity-theoretic model of
parallel real-time computations [3, 4, 5]. Timed
ω-languages are in particular suited for describing
(or being described by) the interface between nodes
in an RTS YNC system. Establishing the semantical model presented here as an abstract machine for
timed ω-languages and deriving further complexity
results for real time is also one of our long term interests.
In all, this paper presents a report of what we
believe to be a powerful tool in placing real-time,
distributed programming on a formal basis. This
is one small step towards this goal; future developments are in the works theoretically, and once developed their implementation should pose little problems given the support already built into the system. In the meantime we want to open a discussion
on model-based versus ad-hoc development of realtime distributed systems. Given the somehow preliminary nature of this development, we do not provide programming examples or testing of the system
at this time.
5.1 Current and future developments
The current version of the RTS YNC system is available on the Web [14] and can be distributed and
modified freely under the terms of the GNU General Public License [7]. Programming and user documentation are also available on the RTS YNC Web
page [14]. Interested parties are encouraged to contact the developers; while people can modify the
code freely and without any requirement to send
back the changes to the developers [7], we kindly
ask that modifications of the code be sent back to us
for possible inclusion in future versions. Feedback
of any nature is also welcome.
At this time we fall well short of the stated goal
that our system allows for formal analysis of the programs. We are currently interested in studying the
possibility of deriving a model and test cases starting from the RTS YNC code itself. The mentioned
timed call graph currently computed by the system
should be viewed as a stub that is to be replaced in
the future by the results of our current research (theoretical research on the matter is in the works).
Once the theoretical foundation is in place, the
system might be extended to include these results.
However, such an extension is highly dependent on
the interest of the applied community in such a tool;
this interest will be a decisive factor in the speediness of future developments of the RTS YNC system. As mentioned before, feedback on the matter
is appreciated and will have a direct influence on the
development process. Featuer requests in particular are welcome, though we cannot guarantee any
speedy answer to these requests—indeed, the future
development of the RTS YNC system is highly dependent on theoretical work, whose time line is impossible to predict (and which has priority over the
development work).
11
Maryland Institute for Advanced Computer
Studies Report No. UMIACS-TR-90-76.
References
[1] G. AGHA, Actors: A Model of Concurrent Computation in Distributed Systems, MIT
Press, 1986.
[2] BOOST C++ libraries. http://www.boost.org/.
[3] S. D. B RUDA AND S. G. A KL, Pursuit and
evasion on a ring: An infinite hierarchy for
parallel real-time systems, Theory of Computing Systems, 34 (2001), pp. 565–576.
[4]
[5]
, Real-time computation: A formal definition and its applications, International Journal of Computers and Applications, 25 (2003),
pp. 247–257.
, Size matters: Logarithmic space is real
time, International Journal of Computers and
Applications, 29 (2007), pp. 327–336.
[6] M. F RANZ , P. H. F R ÖHLICH , AND
T. K ISTLER, Towards language support
for component-oriented real-time programming, in Proceedings of the International
Workshop on Object-Oriented Real-Time
Dependable Systems (WORDS), Monterey,
CA, Nov. 1999, IEEE Press.
[7] F REE S OFTWARE F OUNDATION, The GNU
general public license.
http://www.gnu.org/copyleft/gpl.html.
[8] T. H ENZINGER ,
Z. M ANNA ,
AND
A. P NUELI, Temporal proof methodologies for real-time systems, in Proceedings of
the 18th ACM SIGPLAN-SIGACT symposium on Principles of programming languages,
Jan. 1991.
[9] Y. I SHIKAWA AND H. T OKUDA, Distributed
real-time programming language: RTC++,
Computer Software, 9 (1992), pp. 28–47.
[10] B. N IELSEN , S. R EN , AND G. AGHA, Specification of real-time interaction constraints, in
The First IEEE International Symposium on
Object-Oriented Real-Time Distributed Computing, Kyoto, Japan, Apr. 1998, IEEE Computer Society Press, pp. 206–214.
[11] V. M. N IRKHE , S. K. T RIPATHI , AND A. K.
AGRAWALA, Language support for Maruti
real-time system, tech. rep., University of
Maryland at College Park, 1990. Univ. of
[12] A. P. P ONS, Temporal abstract classes and virtual temporal specifications for real-time systems, ACM Transactions on Software Engineering and Methodology, 11 (2002), pp. 291–
308.
[13]
, An object-oriented language for realtime systems, International Jornal of Computers and Applications, 26 (2004), pp. 31–37.
[14] RTS YNC home. http://bruda.ca/rtsync/.
[15] M. S AKSENA , P. F REEDMAN , AND
P. RODZIEWICZ, Guidelines for automated
implementation of executable object oriented
models for real-time embedded control systems, in The 18th IEEE Real-Time Systems
Symposium (RTSS ’97), IEEE, Dec. 1997,
pp. 240–252.
[16] S. S CHNEIDER, Concurrent and Real-Time
Systems: The CSP Approach, John Willey and
Sons, 2000.
[17] B. S ELIC , G. G ULLEKSON , AND P. T. WARD,
Real-Time Object-Oriented Modeling, John
Wiley and Sons, 1994.
[18] L. S HA , R. R AJKUMAR , AND S. S.
S ATHAYE,
Generalized
rate-monotonic
scheduling theory: A framework for developing real-time systems, Proceedings of IEEE,
82 (1994), pp. 68–82.
[19] A. S KJELLUM , A. K ANEVSKY, Y. S. DAN DASS , J. WATTS , S. PAAVOLA , D. C OTTEL , G. H ENLEY, L. S. H EBERT, Z. C UI ,
A. ROUNBEHLER , AND T HE R EAL -T IME
M ESSAGE PASSING I NTERFACE (MPI/RT)
F ORUM, The real-time message passing interface standard (MPI/RT-1.1), Concurrency
and Computation: Practice and Experience, 16
(2004), pp. Si–S322.
[20] K. TAKASHIO AND M. T OKORO, DROL:
An object-oriented programming language for
distributed real-time systems, in OOPSLA ’92:
conference proceedings on Object-oriented
programming systems, languages, and applications, 1992, pp. 276–294.
RRA, Vol. XXI, Nr. 2, pag. 12-18, 2008
Printed in Romania
Intelligent Store- An Innovative Technological Solution for Retail Activities
Carmen E. STAN, Dan DUMITRESCU, Vasilica CARAS
Institute for Computer, Bucharest, Romania
Doru E. TILIUTE
University of Suceava, Romania
Eugen POP
Research&Development, Engineering and Manufacturing for
Automation Equipment and Systems, Bucharest, Romania
Lucian E. ANGHEL
National Institute for Research and Development in Informatics, Bucharest, Romania
Abstract: Economic, demographic and technological changes establish a new reassessment of the
custom trade. This article introduce the way in which the emergent technology facilities can be use in
retail activities, bringing out new services types for customers and economic agents.
The project set up a new technological infrastructure for an Intelligent Store, bringing in different
technologies: RFID ( for automatic products detection) or interfaces with payment systems based on
RFID, GPS, GIS ( for client localization or store localization and starting proximity alerts ), wireless
communications, mobiel access to information (on PDA or SmartPhone), integrated environments for
data analysis ( Bussness Inteligence) regarding stocks and customer administrationt.
Keywords: mobile communication, marketing, computer interfaces, database management system,
decision-making.
1.
Introduction
Retail trade is an essential component of
economic development, with major social
implications affecting people’s lives and
activities. Careful analysis of the field
identified some miss functionalities.
While leisure time seems to be smaller and
smaller and the daily stress is increasing,
people loose their patience and the
availability to spend a lot of time searching
for products on store shelf or waiting for
paying the products in the basket. One may
notice an increasing need for detailed
information on products, which currently is
not satisfied.
On the other hand, the merchant is interested
in reducing the time wasted in activities such
as provisioning, stock administration or
product inventory. At the same time the
merchant, whose main goal is to maximize
the profit, must be able to
dynamically diversify his supply according to
the customer demands, to make the supply
more attractive (by advertising, information,
promotions in optimum moments), to know
the market trends in order to make the best
decisions his specific activities.
This paper presents an innovative solution in
retail activities, named “Intelligent StoreINTELSHOP”, based on a technological
platform that offers the support for some
attractive and efficient services for customers
and administrative staff. The technological
platform integrates various technologies such
as
RFID
(for
automatic
product
identification), GPS and GIS (for customer
localization and starting proximity alerts),
wireless communications, mobile access to
information on PDA or SmartPhone,
integrated environments for data analysis
regarding
stocks
and
customers
administration, interfaces with electronic
payment systems.
REVIST A RO M ÂNĂ DE AUT OM AT ICĂ
2.
System Implementation
The goal of the proposed system is to make
available the advanced technology to the
merchants and to make shopping activity more
flexible, easier and even funnier, maximizing
Fig. 2.1. Main services for customers. At
home it may edit a shopping list and transfer
it on PDA. The list will be automatically read
in the neighborhood of the Intelligent Shop.
Inside the store, the customer is guided to the
shelf with the map displayed by PDA. The
RFID reader attached to PDA read detailed
information on products in shopping list
when the customer is in the vicinity of those
products. The total cost of products in cart is
automatically computed.
13
the visibility within Intelligent Store and the
impact on customers.
The main services for clients are shown in
figure 2.1.
These are:
- online
information
on
products
(availability, characteristics, price):
x product identification: selection
from a list and reading RFID tag
x reading information about product
from database and display them to
the client
- customizable offer for loyal clients
- client guidance within the store, towards
the products, using digital map of the
store available on a mobile device
(PDA or Smart Phone)
- interfaces for electronic payment systems
14
The services provided by system for store
are:
- stock administration:
x product registration in warehouse
and writing in RFID tag,
x product monitoring on shelf
(intelligent shelf)
x count total price of products in
customer cart (Self –Checkout)
Other services of the system aim to offer
support for marketing strategies:
- customizable offers
- establishing the availability of products
within client list, localization of
products on shelf, client guidance using
the digital map of the store
- information on product traceability (the
history of product states from
acquisition to sale)
- online information about products and
promotions.
A. System architecture
INTELSHOP system has a multi-layer
architecture. In the middle of this
architecture are:
- Back-office application server
- Information repository server
- Access middleware
- HMI – Human Machine Interface
The novelty of the proposed system consists
in the integration into a unitary platform,
robust and reliable, able to bear various
market chain specific services.
The application server allows direct
integration of any new developed service
module as well as services distribution
through a server network.
The information repository server was
designed to store and manipulate data and
interact with application server[9].
The middleware server deals with the
actions related to customer authentication,
session management, validity duration of
client request and data presentation.
Finally, HMI provides interactivity and
innovative features.
3. System components
Currently we realized the following system
components which have to be integrated at the
level of functional model:
- Platform for online data acquisition
through RFID communication channels
- INTELSHOP Web portal and Web services
- Digital map of an area from within
Bucharest city with location of store chain.
The map is integrated into Web portal
facilitating client orientation
- Application for mobile device PDA
(MapPROD) that allows clients to quick
find products on shelf, to get extended
information on products, customized bids,
etc.
- Services for store administration
- CRM
(Customer
Relationship
Management) services.
3.1. The platform for online data acquisition
3.1.1. The hardware subsystem of the
platform for online data acquisition with
RFID communication
The platform for online data acquisition
comprises a hardware subsystem that includes
specific RFID equipment (anthena, USB RFID
Reader, tags) and a software subsystem. The
hardware subsystem uses USB interface to
communicate with RFID readers and, by means
of a software module, ensures the following
functions:
- Scans for available RFID readers and
manage the list of RFID readers
- Selects a RFID reader from the list based
on its ID number
- Opens the communication channel with the
selected device, creating a data structure
and an object associated with the device,
within the DLL library
- Transfers data towards RFID reader
15
Fig.3.1.1 Scans for available RFID readers and manage the list of RFID readers
3.1.1.2 The hardware subsystem of the
platform for online data acquisition
The software subsystem is implemented in
client-server architecture, different applications
communicating via Ethernet protocol. The
virtual core of client-server communication is a
Web service which includes direct access
functions to central databases. The Web
services, hosted by central server system, may
be accessed by software client allowing database
updating according to products that flow from
the store. Client application software is
implemented with Visual C++ Builder and uses
object belonging to TClientSocket class.
Acquisition application software implements
and manages data streams through USB
interface, embeds the communication interfaces
with system central server and allows:
- Transmission of manual commands
towards
equipment
and
automatic
acquisition of data stored by transponders in
the RF field of connected RFID.
- Communication with several RFID
equipment simultaneous connected at
different USB ports of Host PC.
Acquisition application software implements
and manages data streams through USB
interface, embeds the communication interfaces
with system central server and allows:
- Transmission of manual commands
towards equipment and automatic
acquisition
of
data
stored
by
transponders in the RF field of connected
RFID.
Communication
with
several
RFID
equipment simultaneous connected at
different USB ports of Host PC.
3.1.2.
Web Portal INTELSHOP:
http://intelshop.itc.ro
The next platform component, INTELSHOP
Web portal, ensures an interactive interface
for customers using data fetched directly
from database server. It is available at the
web address: http://intelshop.itc.ro. It allows
customers to browse products as any other ecommerce portal but, in addition, it gives the
possibility to edit the list of products, transfer
it on the PDA. The software application for
mobile devices is downloadable from the
Web server via portal.
The third component of platform is the digital
map which can be accessed by customer through
Web portal. It helps customers to locate the most
convenient location for shopping. Figure 4.1.2.1
displays the map with the location of three stores,
available on Web portal.
Fig. 3. Information about store localization on the map
16
3.1.3. MapProd – the application for
mobile devices
In current implementation the mobile device
is any PDA with built-in GPS facility,
attached to a RFID reader[8] with CF card
slot, as shown in figure 3.1.3.1.
The fourth component, the application for
mobile devices, MapPROD, ensures customer
orientation and information within the store.
Fig. 3.1.3.1. RFID Receiver for PDA, Mobile device for client localization
MapPROD application combines the
localization facilities of GPS client with those
of the RFID reader and wireless database
access in order to provide the following
facilities:
- Displays product characteristics when the
customer is in the vicinity of the product
- Displays information for customer
- orientation, helping him to locate the
product from shopping list on store shelf.
- Notify customer in the proximity of an
- Intelligent shop and displays those
products from the shopping list that are
available in the store.
The proximity function relies on customer
coordinates (long, lat) supplied by GPS, the
store coordinates being already known by the
application.
Figure 3.1.3.2. exemplifies the way in which
the optimum route to the product is drawn on
PDA display.
Fig. 4.1.3.2. PDA used for customer information
17
3.1.4.
Services for store administration
3.1.4.1 The commercialization chain
throught stores
One of the most complex systems of the
platform is that offering services for store
administration[10].
The commercialization chain through stores
covered by our project contains several sub
chains that must be integrated in different
ways, according to the business target settled
in a certain period:
- Drawing up the store bid
- Administration of product providers
- Product acquisition
- Customer administration
- Identification of product requirements
from customers
- Management of geographical localization
of products within the store
- Warehousing/temporary
storage
of
products
- Commercialization of products by the
store
3.1.4.2.
Stocks administration
subsystems
The complex tasks are accomplished by
several subsystems, each subsystem being
conceived in two levels:
1.INTELSHOP management center level
2.INTELSHOP store level
One of these subsystems, the subsystem of
stock management and customer relationship
management (CRM) is presented below.
INTELSHOP management center level
contains a Web server (Microsoft IIS) which
provides interfaces for stock management
applications,
customer
relationship
management applications as well as for RFID
tags management application and a database
server (Microsoft SQL 2005) that ensures
database management of INTELSHOP
system.
INTELSHOP Store level comprises three
components:
- Clients for Web services of RFID tags
management
- Clients for stock management subsystem
- Clients for CRM subsystem
The subsystem for stock management
contains, on its turn, the following application
components:
- Management of warehousing places
- Management of products input/output
- Management of products among different
storing places
- Management of returned products.
As an example, the flowchart of product
movement
management
and
stock
management is depicted in figure 3.1.4.2.1.
Fig. 3.1.4.2.1 Stock Management: flowchart of processes involved
18
The interfaces between RFID tags reader
application
and
stock
management
application were achieved as Web services
and provides following functionalities:
- Assigning RFID tags to products
- RFID deactivation, necessary for
shopping cart generation
- Labeling returned products.
Finally, the CRM subsystem has two
application components too: customer
management and sales management.
REFERENCES
4. Conclusions
Our research studies lead to the achievement
of an innovating system that puts the retail
trade in a new and revolutionary perspective.
The results we achieved accomplish the
following requirements:
- Contributes to the increasing of
Romanian economy in the sphere of
retail trade, by new working technologies
and services
- Stimulates the Romanian store chains to
penetrate European and global markets
offering innovative technologies
- Puts up a hardware-software support
platform to carry on trade activities
- Prompts the present stores to adopt and
use the system
[1] G. O. Young, “Synthetic structure of
industrial plastics (Book style with paper
title and editor),” in Plastics, 2nd ed. vol.
3, J. Peters, Ed. New York: McGrawHill, 1964, pp. 15–64.
[2] W.-K. Chen, Linear Networks and
Systems (Book style).
Belmont, CA:
Wadsworth, 1993, pp. 123–135.
[3] H. Poor, An Introduction to Signal
Detection and Estimation. New York:
Springer-Verlag, 1985, ch. 4.
[4] B. Smith, “An approach to graphs of
linear forms (Unpublished work style),”
unpublished.
[5] E. H. Miller, “A note on reflector arrays
(Periodical
style—Accepted
for
publication),” IEEE Trans. Antennas
Propagat., to be published.
[6] J. Wang, “Fundamentals of erbium-doped
fiber amplifiers arrays (Periodical style—
Submitted for publication),” IEEE J.
Quantum Electron., submitted for
publication.
[7] C. J. Kaufman, Rocky Mountain Research
Lab.,
Boulder,
CO,
private
communication, May 1995.
[8] ARC1008 PDA Smart Card Reader - ISO
14443, type A/B
[9] ASP.Net 2.0:A Developer's Notebook,
Wey-Meng Lee, Editura O'Reilly 2005
[10] Sql Server 2005 Analysis Services,
Reed Jacobson, Stacia Misner, Editura
Microsoft Press 2005
AR2-5.doc
RRA, Vol. XXI, Nr. 2, pag. 19-26, 2008
Printed in Romania
Automatic System for Optimization of Operation of a Gas
Cogeneration Power Plant
Ion MICIU
Department: Industrial Automations
Institute: Engineering Automation – Research and design Institute for Industrial Automation - IPA SA
Address: Bucharest 014495 Romania, Calea Floreasca 169, Sector 1
ROMANIA
[email protected], [email protected], http://www.ipa.ro
Abstract: The system is made with main distributed components:
- first level: Industrial Computers placed in Control Room (monitors thermal and electrical processes
based on the data provided by the second level);
- second level: PLCs which collects data from process and transmits information on the first level; also
takes commands from this level which are further, passed to execution elements from third level;
- third level: field elements consisting in 3 categories: data collecting elements; data transfer elements
from the third level to the second; execution elements which take commands from the second level PLCs
and executes them after which transmits the confirmation of execution to them.
The purpose of the automatic functioning is the optimization of the co-generative electrical energy
commissioning in the national energy system and the commissioning of thermal energy to the consumers.
The integrated system treats the functioning of all the equipments and devices as a whole: Gas Turbine
Units (GTU); MT 20kV Medium Voltage Station (MVS); 0,4 kV Low Voltage Station (LVS); Main Hot
Water Boilers (MHW); Auxiliary Hot Water Boilers (AHW); Gas Compressor Unit (GCU); Thermal
Agent Circulation Pumping Unit (TPU); Water Treating Station (WTS).
Keywords: Cogenerative Power Plant, Automation System, Control, Monitoring, Real Time
1. Theoretical considerations regarding
the Cogenerative TPS
1.1.
Overview [1]
The concept of co-generation means the
combined production of electrical (or
mechanical) energy and of thermal energy
based on the same primary energy source. The
produced mechanical energy can also be used
for the operation of auxiliary equipments (for
example, compressors and pumps). The thermal
energy can be used for heating, or for cooling.
The cooling process is attained thru an
absorption unit which operates with hot water,
steam or gas at high temperatures. In the
process of operating a conventional value
power plant, a significant quantity of heat is
exhausted in the atmosphere, by some cooling
circuits (steam condensers, cooling towers,
water coolers from the Diesels / Otto engines),
or by residual gases. Most of this heat quantity
can be retrieved ant used for thermal necessities,
therefore increasing the efficiency from 30~50%
(the case of a normal power plant) to 80~90% (in
case of a cogeneration power plant). Considering
total efficiency as a parameter, the classic systems
of separated production of thermal and electrical
energy get a total efficiency of 58% compared to
the cogeneration system which has a value of 85%
total efficiency. The systems which were efficient
and could use alternative fuels were on demand
and more important in the phase of rising prices
and of doubt fuel supplying. More than the low
prices for used fuels; the cogeneration diminishes
the environmental pollution. For these reasons, the
governments of Europe, USA and Japan took
position in the favor of increasing the
implementation of cogeneration. There are three
principal forms for encouraging the use of
cogeneration: Regulations or exoneration from
regulations; Monetary stimulations; Financial
support for research and development.
20
The researches, the development and the
demonstrative projects created over the last
25 years conducted to a significant
enhancement of the technology which
become today mature and reliable.
Meanwhile, new techniques are in research,
for example the combustion cells.
1.2. Performance parameters for the
Cogeneration Systems [5]
The main parameters are in the specialty
literature: The efficiency of the first
„engine” (for example, gas turbine, Diesel
motor, steam turbine); The electrical
efficiency; The thermal efficiency; The
total
energetic
efficiency
of
the
cogeneration system. The heat quality is
lowered compared to the one of the
electricity and is decreasing with the
available temperature. For ex., the heat
quality in the case of hot water is reduced
compared to the case of steam. Therefore,
at the first analysis it could seem that it’s
not indicated to sum electricity and heat.
1.3. Actual Cogeneration Technologies
[11], [2]
1.3.1. Cogeneration types
Most of the cogeneration systems can be
characterized as topping systems or as
bottoming systems. In the topping systems,
a high temperature fluid (residual gas,
steam) fuels an engine for producing
electricity, while the low temperature agent
is utilized in thermal processes for heating /
cooling the extent. In the bottoming
systems, the high temperature agent is
produced mainly for a process (for
example, in a furnace, or a cement oven);
after the end of this process, the hot gases
are used directly for powering a gas turbine
if the pressure is proper, or indirectly for
producing steam (in a recuperation boiler),
after which is used for powering a generator
with steam turbine. The temperature ranges
for the two system types are presented in
figure 1.
Fig. 1. Temperature ranges for topping and bottoming
Cogenerative Systems
The main cogeneration system types are:
steam turbine cogeneration system –3
major components: a heat source, a steam
turbine and heat tank; operates with Rankine
cycle, or in a base form, or in improved
versions (with reheating of steam and prior
heating of the regenerative water)
gas turbine cogeneration systems – operates
open / close cycle;
cogeneration systems with mutual internal
combustion engines–operates with Otto or
Diesel cycle;
cogeneration systems with combined cycles
– topping temperature cycle, eliminates the heat
that is retrieved and utilized by the bottoming
temperature cycle for producing supplementary
electrical (or mechanical) energy; operates with
Joule – Rankine or Diesel – Rankine combined
cycle.
fuel cells – electrochemical devices which
converts the chemical energy of the fuel
directly
into
electricity,
without
the
intermediary states of combustion and
mechanical work
cogeneration systems with Sterling engine
– operates in Sterling cycle.
A comparison between the performances of
these cogeneration systems is illustrated in
Table 1. bellow shown:
21
Electr. power
Mean anual
availability
MW
%
100% load
Gas turbine
0.5-100
90-95
Gas turbine (open cycle)
0.1-100
Gas turbine (closed cycle)
System
Joule-Rankine combined cycle
Diesel engine
Mutual internal combustion engine
Fuel cells
Sterling engine
Total
efficiency
Heat power
ratio
50% load
%
__
14-35
12-28
60-85
0.1-0.5
90-95
25-40
18-30
60-80
0.5-0.8
0.5-100
90-95
30-35
30-35
60-80
0.5-0.8
4-100
77-85
35-45
25-35
70-88
0.6-2.0
0.07-50
80-90
35-45
32-40
60-85
0.8-2.4
0.015-2
0.04-50
0.003-1.5
80-85
90-92
85-90
27-40
37-45
35-50
25-35
37-45
34-49
60-80
85-90
60-80
0.5-0.7
0.8-1.0
1.2-1.7
Electrical efficiency %
Table 1.. Technical characteristics of the cogeneration systems
1.3.2. Gas turbine cogeneration systems
[11]
The gas turbines, with simple or combined
cycle, are for the moment the most often used
technology in the cogeneration systems of
mean and high power. The gas turbines have
been developed as heavy-duty units for
industrial and adjacent utilities, or for ship
engines, compact and efficient. Generally,
they are capable of a fast startup and fast
response at the load change. Both gas turbine
projects were successfully used in
cogeneration, having as main advantages the
initial low cost, the capacity of modifying the
fuel, the high quality heat easy to recover and
also a significant efficiency in case of greater
dimensions. In addition, the „Ready to use”
commercial availability contributed to a large
spread of application of this type. A gas
turbine can operate in open cycle or closed
cycles.
1.3.3. The thermodinamic performance of
gas turbine cogenerative systems
1.3.3.1. The efficiency and the power–hea
ratio (PHR) [3], [5]
The rated electrical efficiency of little to
medium gas turbine systems, generally are in
the range of 25%-35% efficiency. The bigger
systems, recently built have a nominal
efficiency of 40-42% using the high
temperature of the exhaust gases (1200 1400 C). The total efficiency is in the range
of 60-80%. The power–heat ratio is in the
range 0.5-0.8. A significant portion of the
power output of the turbine, many times over
50%, it consumes for the powering of a
compressor, resulting a relatively low
electrical efficiency (compared to a
reciprocally engine of same power). In the
case of a big pressure ratio, the air cooling in
an intermediary compressing state can be
applied. A significant rise of the electrical
efficiency can be obtained by re-heating the
air using the residual gases. In this case, the
recoverable heat from the residual gases, after
the regeneration heat exchanges process ends,
decreases and the power – heat ratio (PHR)
value increases. In case of the cogeneration,
as for the combined gas-steam cycles, there is
no need for adding an air regenerative preheating. The maximal recoverable heat
depends on the minimal accepted temperature
for the residual gases. If there is sulfur in the
fuel, the temperature of the residual gases
cannot be smaller than 140-165 C to avoid
the forming of the sulfuric acid. If there is no
sulfur in the fuel–the case of the natural gas,
residual gases temperature can be in the range
90-100C.
22
1.3.3.2.
The effect of environment
conditions and of partial charging
over output power and efficiency of
gas turbine [7]
The air is aspired into compressor at
environmental conditions. Initial temperature
and air density will act directly over
compression
conditions
(power
of
compression, fuel which is burned, necessary
fuel to obtain a specific temperature of
turbine). This means that final output power,
efficiency, rate and temperature of the flux of
residual gases at turbine output (recoverable
heat at consequently), are functions of
environmental conditions which must be
considered in project. Capacity of a turbine
decreases
if
increases
environment
temperature or altitude of mounting (with 24% at each increasing of altitude with 300
m). Partial charging of turbine has a strong
effect over electrical efficiency: the charge
decreasing determines decreasing of electrical
efficiency.
2. Functions of an applied Optimization
System
NOTE: In order to describe the technological
functions of the Cogenerative Gas Power
Plant, for exemplifying has been chosen an
application made by IPA SA at TPS Bacau,
Romania, into 2007 year: Automatic Control
and Monitoring System of the unit # 3.
The Automatic Control and Monitoring
System is compounded from the following
main distributed components:
- level no. 1: An industrial computer IL 43
Siemens (placed in Control Room) in which
is implemented an application program
(developed on PCS7 Siemens base program)
which monitories thermal and electrical
processes from Power Plant based on data
delivered via Ethernet (through optical fiber)
by level. 2;
level no 2: PLCs S7 300 Siemens
(interconnected at level 1 through Ethernet)
which collects the data from process using
the field elements from level 3 (transducers)
and, based on an application program,
transmits information to level 1 and receives
- from this level the commands for level no.
3; these PLCs controls the Power Plant
equipments as follow: Turbine & Generator
unit – GTU (U3 CBC01) (own control
supervised via satellite and connected via
Ethernet at IPA’s PLC: U3 CBC21); Gas
Compressor Unit – GCU (U3 CBC11) (own
control supervised via satellite and connected
via Ethernet at IPA’s PLC: U3 CBC21);
Main Hot Water Boiler – HWMB (U3
MBR01) (controlled and monitorised by
IPA’s PLC: U3 CBC21); Auxiliary Hot
Water Boiler – HWAB (U3 HMA11)
(controlled and monitorised by IPA’s PLC:
U3 CBC21); Heat Exchangers no. 1, 2, 3 –
HE#1, HE#2, HE#3 (U3NDD01, U3NDD01,
U3NDD03) (controlled and monitorised by
IPA’s PLC: U3 CBC21); Auxiliary
Installations (valves, slide valves, pumps,
cooling ventilators, etc.) (controlled and
monitorised by IPA’s PLC: U3 CBC21);
- level 3: Fields Elements as follow:
Transducers (4-20mA) for pressure, level,
flow, temperature, electrical power, etc.;
Data Transfer Elements (signal cables,
PROFIBUS cables, Ethernet cables, NET
switch converters, etc.); Operation Elements
2.1. General description of a Gas
Cogenerative System Operation
The control of the electricity generation will
be executed by the control unit of the gas
turbine unit (GTU) - U3 CBC01. Their key
control devices are some special configured
PLCs which are operating autonomous to any
of the other control devices as the requested
set point for the electricity generation is
manually settable. Additionally to the
manually setting of the requested power
generation capacity value by the control
devices of the gas turbine unit there is also
the possibility of setting the requested power
generation capacity value by the overall
HMI-monitoring system related to the control
unit U3 CBC21. The required fuel (natural)
gas for the GTU will be prepared and
delivered at a pressure level of some 26.0 bar
g by an also autonomous controlled and
operating gas compressor unit (GCU). The
respective control unit or PLC for the GCU is
tagged as U3 CBC11. For this fuel gas Bacau
23
provision the gas compressor unit (GCU) is
considered to be operated automatically and
autonomous by its control unit or PLC-unit
U3 CBC11. The operation of the GCU is
entirely and exclusively controlled by the
PLC-unit U3 CBC11 and is not depending for
starting and operating to any other control
device / PLC. Nevertheless it is possibly to
start the GCU remotely by the PLC-unit U3
CBC21 which is designated for the HotWater-System (HW-system) but contains also
some superior control duties for the entire
plant (unit #3) as some essential signals are
exchanged between U3 CBC11 and U3
CBC21. For the heat extraction from the
delivered exhaust gas into an hot water
system (HW-system) a main HW-boiler is
foreseen which is capable of a thermal heat
extraction of up to 22 MWth at nominal
power generation capacity. To obtain the
contractually specified heat generation
capacity of 25 MWth an auxiliary HW-boiler
with an additional heat generation capacity of
3.25 MWth get established beside the main
HW-boiler. Finally the heat extraction out
from the exhaust gas of the running gas
turbine and its transfer into the secondary
circuit HW-network (district heating system
of the city of Bacau) get controlled by the
PLC-unit U3 CBC21. Furthermore the PLCunit U3 CBC21 is controlling some auxiliary
systems as the instrument air provision units,
some building ventilators, an emergency
cooling equipment for the primary HWcircuits etc. For the monitoring and remote
operation of the new unit #3 two visualization
computers or HMI-stations are foreseen and
are located in the central control room (CCR)
of the power plant of TPS-Bacau. The first
HMI-station is exclusively considered for the
monitoring and operation of the gas turbine
(and is provided by the gas turbine
manufacturer Turbomach) as the second
HMI-station (with a visualization system of
Siemens, type PCS7) is considered for the
monitoring and visualization of the HWsystem, the gas compressor unit (GCU) and
all side and auxiliary equipment as well as for
some superior operational demands of the
entire unit #3 (and is provided by IPA SA).
The CCR is located inside the main
machinery building of unit #1 inside TPS-
and which is some 300 m away from the
location of the new unit #3.
Operation of GTU leads by generation of
electricity
Due of the nature of gas turbines in general it
is strongly recommended by the manufacturer
to run the gas turbine best at rated capacity
(100%) or if deviating from full capacity
operation to operate it inside a range of
minimum 65% up to 100% of unit nominal
capacity. Furthermore and as mentioned
above it is strongly recommended to lead the
operation of the new generation unit #3 by
the generation of electricity. According to
this electrical generation priority the
generation of hot water (HW) is in
dependency of the thermal energy content of
the exhaust gas delivered by the gas turbine at
any operational stage. The set point for the
requested capacity of power generation can
be inserted manually into the control unit of
the GTU–U3 CBC01–at the local screen
inside the control compartment of the GTU or
at the HMI-station of the GTU (located in the
CCR) or at the superior HMI-station (PCS7type) of the HW-system (also located in the
CCR. If the gas turbine is running at any set
and automatically controlled capacity the cogenerated waste heat out of the exhaust gas
shall be extracted consequently at full
capacity and transferred into the HW-system
and further on into its secondary circuits
which are hydraulically linked with the HWdistrict-network of the city Bacau.
Operation of GTU leads by generation of
heat (Hot Water)
Though, not advisable at all, the led operation
of the gas turbine unit according to the
requested heat demand is also considered
following a strong request of the operator and
future owner of the new unit (TPS-Bacau).
Therefore an automated program has to be
created and programmed inside the PLC-unit
U3 CBC21 (which is beside its control tasks
towards the heat extraction and HW-systems
also designated for superior control duties),
which allows the setting of the thermal HWdemand as prior operational set point for the
entire gas turbine unit.
For the heat demand led operation of the gas
turbine unit a respective control loop has to
be established inside the PLC-unit U3
CBC21. This control loop shall control the set
point for the electrical power generation set
point inside U3 CBC01 which is than
corresponding to the providing of a respective
heat generation according the following set
point curve:
the intake control gate valve is completely
closed – there will remain a certain rate of
exhaust gas inflow into the main HW-boiler
(equal to the leakage share of the control gate
valve). The respective leakage rate of the
control gate valve is figured by 1% meaning
the maximum expected heat intake into the
HW-boiler will be up to 220 kW. To prevent
any excess temperature at the HW-output of
the HW-boiler an emergency cooling system
is foreseen.
The control loop is shown on the following
control loop diagram:
Note: The above stated capacity figure for
thermal and electrical generation capacities
are varying slightly from the respective
nominal figures of the gas turbine and the
main boiler; this is caused by the empirical
elaborated curve values , which are taken
during respective operational test sessions.
2.2. Main Hot Water Boiler U3 MBR01
BB001
The exhaust gas from the GTU is lead into
the Main Hot Water (HW) Boiler U3 MBR01
BB001. Depending on the HW-demand by
the heating net of the city of Bacau this high
temperature exhaust gas flow can be used for
heat extraction by the main boiler or if no
respective thermal energy demand is given
the exhaust gas flow can be bypassed on the
main boiler into the exhaust flue gas
chimney. For the control of heat extraction a
respective pair of inverse to each other acting
control gate valves is located at the intake
conduct to the boiler as well as in the bypass
conduct.
If, for whatever operational reason, the main
HW-boiler is completely bypassed - meaning
Temperature control on HE output acting on input
If the control valves in the primary circuit(s)
of the heat exchangers are in a limited
position due of the minimum limit controller
from the secondary circuits and the HWoutlet temperature is still decreasing the limit
controller U3 NDA01 DT003(2) is
intervening and will partly open the HWcontrol valve at the primary circuit outlet U3
NDD01/02/03 AA050 to increase the heat
intake into the heat exchanger (originating
from the HW-boiler).
20
Simplified P&I-diagram of HE: U3 NDD01
2.4.
Simplified P&I-diagram of Main Hot Water Boiler
2.3. Hot Water Heat Exchangers
The thermal energy of the generated hot
water (HW) from the main HW-boiler – U3
MBR01 BB001 – and in case of maximum
thermal demand additionally from the
auxiliary HW-boiler – U3 HMA11 BB001 –
will be transmitted via a total of 3 units of
HW-heat exchangers into the HW-network of
the city of Bacau. The rated capacity of each
HW-heat exchanger is 12.5 MWth.
Corresponding to the maximum generated
HW-heat of 25.0 MWth – by the main HWboiler plus the auxiliary boiler – the operation
of the three HW-heat exchangers will be in a
2+1 –redundancy configuration (equal to 2 x
50% of normal capacity plus 50% redundant
capacity). According to the redundancy
configuration of 2+1 it is foreseen
a) to operate only one of the three HW-heat
exchanger or
b) maximum two of the three units
Auxiliary Hot Water Boiler
If the heat generation capacity of the main
HW-boiler is insufficient to serve the demand
of the HW-consumption, the auxiliary HWboiler can provide up to 3.0 MWth of
additional HW. The heat generation of the
main HW-boiler is always dynamised
indicated on the FMCS’s monitoring system
(HMI) by measurement loop U3 NDB01
CF901. Following the indication of the
generated HW-capacity (measurement range
0 to 22.0 MWth) the operational staff can
recognize any HW-shortage and will
exclusively decide about any additional
generation of HW by the auxiliary HWboiler. Consequently the operational staff of
the power plant will initiate any starting or
stopping of the auxiliary HW-boiler by
manual commands from the HMI-system
located in the central control room (CCR) of
the power plant. The HW-circuit through the
auxiliary HW-boiler will be controlled
externally by the superior HW-PLC tagged
U3 CBC21 via the HW-flow rate. The
minimum HW-flow rate through the auxiliary
HW-boiler shall be 50 m3/h as the rated
capacity is 134 m3/h providing a rated heat
capacity of 3.0 MWth at a HW-circuit
differential temperature of 20 K.
21
4. References
[1] Eremia M., Electric Power Systems,
Editura Academiei Romane, Bucuresti,
2006
[2] Madarasan,
T
si
Balan,
M.
Termodinamica tehnica, Editura Sincron,
Cluj-Napoca, 1999.
3. Conclusions
Implementation of this system in a Romanian
Cogenerative Power Plant has the following
advantages: obtaining a high efficiency and
combustible saving, limited efforts for
developing a new application in a short
period of time, and high performance of the
system in solving the demands of
applications. The system was configured
easily, and it has worked very fast because
the communication protocol transmits just the
information
needed.
The
prominent
advantages of the process control system are
the following:
a) - favorable specific heat consumption
b) - optimal utilization of the waste heat
during the winter-summer seasons
c) - saving the cost of investment by use of
the supplementary firing
d) - stable electric power in the power plants
supplying cogenerated electricity and heat.
[3] Kirillin V. A., Sicev, V. V. si Seindlin,
A.E., Termodinamica, E. S. E. Bucuresti,
1985.
[4] Stephan, K. und Mayinger, F.,
Thermodynamik, Band 1 und 2, Springer
- Verlag Berlin /Heidelberg, 1992.
[5] Hahne, E., Grundlagen der Technischen
Thermodynamik Band 1 und 2, Insitut
furThemodynamik und Warme technik
der Universitat Stuttgart
[6] Astrom K., J. Wittenmark: Adaptive
Control, Addison Wesley Company, 1989
[7] Fleming
P.J.
Application
of
Multiobjective
Optimization
to
Compensator Design for SISO Control
Systems, Electronics Letters, Vol.22
[8] Gill P.E., Murray W. Numerical Linear
Algebra and Optimization, Vol.1,
Addison Wesley
[7] Selic B., P.T. Ward: The Challenges of
Real Time Software Design, Embedded
Systems Programming, Miller Freemans
Inc., Oct. 1996
[8] Selic B., G. Gulliksons, P.T. Ward: Real
Time Object Oriented Modelling, John
Wiley & Sons, 1994
[9] W.
Wang
–
Designing
Secure
Mechanisms for Online Processes
[10] Selic B., P.T. Ward: The Challenges
of Real Time Software Design,
Embedded Systems Programming, Miller
Freemans Inc., Oct. 1996
[11] Lipper, T., Setetter, H., Krzyslak, P.
Calculation and Diagnosis of Thermal
Cycles inApplication, in: Proc. Xth Int.
Conf. "Steam and Gas Turbines for
Power and CogenerationPlants". Karlovy
Vary, Czech Republic Oct. 1994, p. 178187.
AR2-3.doc
RRA, Vol. XXI, Nr. 2, pag. 27-31, 2008
Printed in Romania
SINTESERV – AN INFORMATION SYSTEM READY TO ENHANCE THE
RELATIONSHIP BETWEEN LOCAL AUTHORITIES, CITIZEN AND
BUSINESS ENVIRONMENT
Alexandru BOTU, Senior Researcher, IPA SA
Adrian BADOIU, Senior Researcher, IPA SA
Sanda PETRESCU, Senior Researcher, IPA SA
Vasilica VLAD, Senior Researcher, IPA SA
Gheorghe MATEI, Senior Researcher, IPA SA
Abstract: The fast progress of the ITC field provides new opportunities of communication and
interconnection between citizen and institutions, determining radical changes in the behavior of both
citizen and institutions and the development of the local communities.
The SINTESERV project proposed the implementation of a Regional Integrated Information System based
on interconnection of public institutions and aimed to provide electronic services to citizens and business
environment. The project coverage area is the region seen as a geographic area with a distinct profile,
well structured from the point of view of social and economic relations. The pilot IT system resulting from
the project is in course of implementation in Dambovita County. Featured by a modular and flexible
design, by interoperability and open character, the system can be extended in other areas, with minimal
costs.
Keywords: e-Government, electronic services, interoperability, web services
1. Introduction
The main objective of the SINTESERV
project is the implementation of a regional
Integrated Information System based on
interconnection of public institutions and
aimed to provide electronic services to
citizens
and
business
environment.
SINTESERV
information
system
interconnects
public
administration
institutions of the Dambovita County as the
County Council, its subordinated institutions,
the City Halls and the Local Councils
subordinated institutions. The system is
accessible via Internet and it comprises
hardware
and
telecommunications
infrastructure, interconnected databases,
software applications running at the premises
of the institutions, an Internet portal to deliver
electronic services for citizens and business
environment. New electronic services will be
identified and implemented as institutions
from various fields (health, education,
culture, utilities) will be connected into the
system.
The
applications
already
implemented within the project are integrated
at the level of Dambovita Local County
portal.
The SINTESERV information system will be
exploited and maintained by a public-private
partnership including the County Council and
local representatives of the business
environment as stakeholders. The system
beneficiary is the Dambovita County Council
but the project real beneficiaries are the local
communities.
28
2. The System Architecture
3. Project Software Applications
The SINTESERV system can be defined as a
collection of software applications and
electronic services running on a common
high performance platform and delivering
services to the local public administration
institutions,
citizen
and
business
environment. The set of applications was
selected based on the inquiries carried on in
the first stage of the project in the county City
Halls.
3.1. Budget by Programmes Application
The e-Government software applications are
running on the central server: Budget by
Programmes (an application for the
management of the local authorities’
programmes and projects), Local Council
Electronic Library, Local Taxes and Fees, ELearning for the Civil Servants, Document
management.
The only exception is “Community
Information Centre” application which is
running on the server placed at the County
Library.
The application tracks the institution budget
from the initial definition stage until the end
of the financial year. The application
manages the expenses, extracting the
necessary data for building the annual budget.
As the County Council programmes are
fulfilled, the expenses are tracked by each
approved objective, pointing out the
budgetary balance in various phases, taking
into account all the legal financial
restrictions. The application main functional
modules are: Reports, Administration,
Processing, Tracking of the expenses /
investments, Insolvency, Management of
loans, Maintenance of the budgetary
classified lists, Tracking of the revenues. The
application has a three-tier architecture and is
based on web technologies. Figure 2
presents the management of classified list
menu.
It is a distributed system and consists of: a
central server placed at the County Council, a
server placed at the County Library,
communication applications using web
services running on the City halls servers
(figure 1).
Fig.2. Budget by Programmes - Management of the
classified lists
Fig.1. General structure of the information system
29
3.2. Local Council Electronic Library
Application
The application provides access to the Local
Council and City halls archives of decisions,
issued in the county towns and villages. It is a
software application for the storage, search
and publication on web of the decisions and
decisions drafts issued by the County Council
and Local Councils within Dambovita
administrative unit. Because the material and
human resources are relatively limited in
small localities, the software application is
hosted and maintained by the County
Council.
The application has a public section which
main functions are the web publishing and
document search (by locality, document type,
document number, issuing data, issuing
department, field, keywords) and a restricted
access section for document storage into the
database. Both section are also divided in two
subsections each processing documents
originated from two different sources: County
Council and Local Council. In figure 3 is
presented the application search page. The
application is implemented using web
technologies. The user has on his side only a
simple web browser for accessing the
application.
3.3. Local Taxes and Fees Application
Local taxes and Fees Application belongs to
eTax category of applications and it is aimed
to take over, store and publish on the web the
fiscal data of the taxpayers (natural or legal
persons) who request this electronic service.
The data exchange is operated over Internet.
The application uses web technologies and it
is geographically distributed. It comprises
two main parts. First part is the tax and fees
application placed at the central server in the
County Council headquarters. The second
part is represented by modules placed at each
tax office in the localities of the county, for
interfacing with the local tax application.
Overall, it can be viewed as an aggregate
built of the web applications implemented
within the project and local tax applications
provided with interfaces to extract data and
publish it on the web at taxpayers’ request.
The application was designed and
implemented with the aim to provide the tax
payers the facility to see their fiscal status by
Internet. The application covers the whole
county, exception being the towns which are
already running similar applications.
The continuous data refresh process is based
on the communication using web services
over Internet and on the interoperability with
the tax management systems in exploit.
In figure 4 it is presented the application start
page.
Fig.3. Local Council Electronic Library Application –
Search page
Fig.4. Local Taxes and Fees Application - Start page
30
3.4. e-Learning for the Civil Servants
The application is web technologies based
and it is expected to increase the quality of
services paid to citizen and public servants
and to reduce significantly the costs and
spaces needed for paper documents storing,
The application meets the requirements of a
high performance e-Learning platform. The
system main functions are as following:
Management of the course content
(available for lecturers), functions available
to assist the students in the learning process,
communications functions available to all
users and functions for the management of
the learning process (available also for the
lecturers).
A special attention was paid to the
assessment of the students, the system
providing a variety of assessment tools:
courses with published tests, available all the
time the course is opened, courses with
scheduled tests (published sequentially at
announced times), courses with tests at
which solutions are sent by up-loading files.
The test are of the following types: quiz tests,
quiz test with TRUE/FALSE choice,
keywords tests in which it is required to fillin empty fields, homework, projects, essays
etc. The application is implemented in web
technologies. In figure 5 is presented the
Course Management page.
The system functionality covers functions as
general administration, electronic registry,
urbanism, audience, statistics. The system is
based on a three-tier architecture which
ensures scalability, performance and a big
number of concurrent users.
Fig.6. Document Management – Flow of Documents
Page
3.6. Community Information Centre
The Community Information Centre provides
information and counseling by means of an
unique office. The Community Information
Centre must initiate and develop programs for
the public information, to provide day by day
data support for the community (by means of
collections of documents, databases, Internet
links or e-Mail) and to advise the citizen in
getting access to information by various
procedures.
Fig.5. e-Learning for the Civil Servants – Courses
Management page
3.5. Document Management
The application was created to efficiently
store, archive, retrieve and manage scanned
or electronic documents, to define and track
the documents flows in the public
administration institutions.
The Centre will operate at the Dambovita
County Library as a distinct structure.
The application will collect data both from
the county public libraries and from the
central server application “Local Council
Electronic Library” (figure 7).
31
References
[1] eGovernment Good Practice Framework,
http://www.egovgoodpractice.org/index.php?
[2] Poulovassilis – Advanced Databases
Principles
of
Database
Systems
http://www.dcs.bbk.ac.uk/~ap/tea
ching/ADB2004/notes1.pdf
Fig.7. Community Information Center – Main Page
4. Conclusions
Romania has to modernize the central and
local public administration. The methods,
technologies and mentalities of the
Information Society are powerful means to
help reaching this aim.
The Project main expected effects are: an
improved relationship between the public
institutions and the tax payers by increased
transparency and more effective services;
more diversified electronic services (eServices) offered to citizen by public
institutions; more efficient activity of the
county public institutions as result of
interconnection and interoperability; an open
interoperability framework facilitating other
institutions/ software applications/ public
oriented e-Services enhance the system;
hardware, software and telecommunication
infrastructure up-to-date, mainly in rural area;
a support for the Information Society
implementation focused on public authorities,
citizen, companies.
AR2-4.doc
RRA, Vol. XXI, Nr. 2, pag. 32-39, 2008
Printed in Romania
Flood risk reduction solutions in places located near urban areas
Carmen Eleonora STAN, Andrei IANCU, Dan DUMITRESCU
ITC SA
Virgil OLARU
SC IPA SA
Dan MARINOVICI, Daniela ZVORĂùTEANU
USAMV – FIFIM
Gabriel RACOVIğEANU, Gabriel TATU
UTCB
Sorin DINEA
AERODIN
Abstract: This article presents flood risk management solutions in an area located in Bucharest city
based on IT&C technologies(real time parameter monitoring, critical situation alert generating, complex
analysis on historical data for establishing evolution tendencies, simulation and prognosis).
System role is to prevent destructive phonemes, to inform and learn population on how to better know
flood risks and to contribute to a safety habitat. System offers decisional support for specialists and
authorities.
Achieved data has been analyzed by projects execution consortium and has been established concrete
measures to improve existing situation.
There are a sum of good practices accessible from projects portal.
Keywords: flood risk management, monitoring, GIS, SCADA, decision support.
Introduction
Flood is a natural phenomenon and a
component of Terra natural hydrologic cycle.
Last years great floods had huge ecconomic
negattive effects, material damages and
casualties. In 2005 and 2006 Romania
confronted with devastating effects of these
phenomenon.
Apparition of dangerous meteorolo-gical
phenomenon in urban areas crowding imposes
taking great complex decisions in defense work
exploit against flooding from rivers and abutter
lakes. Floods formed in these conditions are
charactrerized by relatively small growing
times, which imposes adoption of small time
exploit decisions. For taking such decisions it is
necessary anticipated simulation of forming
and tranzitting of a possible flood, as to obtain a
data set large enough to see exploit
characteristics, in order to evaluate flooding
risk and taking real time defense measures. In
these days flood exploit systems dispatchers
dont have models to efficiently evaluate flood
risk and optimum exploit model, based on
hidrometeorological forecasted information.
Floods determined by insufficient capacity of
sewage transport network added with
growing
debits
based
on
urban
developmentclimate change represents one of
the most important activities of decision
factors, operatorss and research institutes and
superior education.
Project “Multimedia platform for flood risk
areas real-time monitoring, simulation and
solution generation for optimal usage of
water flow capacity regulation equipments
arround cities – CITYProtect” realised in
CEEX programme elaborated an integrated
solution for reducing urban areas’
vulnerability in correlation with the
exploitation of water-flow regulation
equipments and the evaluation of the
33
sewerage system (through modelling,
simulation and optimization techniques).
System located in beta testing offers complex
monitoring services, control and real time
alerts.
Duing
execution
stages
has
been
accomplished following steps:
realization of an acquisition technologic
platform given in due time, analysis and
decision – monitoring support on-line of
environmental parameters and intelligent
management of risk to flooding;
realization of
analysis holder GIS
(hazard map and risk map of studied
area);
management realization of risk to
flooding services;
operative information, in due time to
decisional factors and population on
steady and mobile access devices;
the elaboration of solutions about
prognosis and evaluation of risk and
flooding in determined areas and
temporary intervals;
the
evaluation
of hydromechanics
installation operating in dinamic regimen to
drain off large water flows;
the elaboration of efficient exploitation
solutions to dam-lakes for safety
functioning;
in this project it was choose as pilot zone
Dambovita river in its Bucharest sector and
has been monitorised three areas: Lacul
Morii, Izvor and Popeúti Leordeni box.
Environment
parameters
has
been
acquisitioned and transmitted at Monitoring
and Control Centre installed at the
consummer (Apele Române).
The proposed system is a SCADA distributed
system which allows the automatic acquisition
of environmental parameters from transducers,
their improvement of processing, the graphic
presentation and radio transmission to the central
dispatcher.
On-line technical monitoring solution means
an integrated acquisition and data processing,
distributed and organised on two levels:
- local level, made of three independent
data acquisition sublevels: sublevel 1 –
Final collector box – Popeúti Leordeni
where has been installed two sensors:
ultrasound automated debitmeter for open
and hydraulic ram channels for flow
measuring, nivelmeter for heights
measuring, sublevel 2 – Zone Izvor where
has been installed ultrasound automated
debitmeter for open and hydraulic ram
channels for flow measuring, nivelmeter
for heights measuring úi sublevel 3 –
Zone Lacul Morii where has been
installed:
ultrasound
automated
debitmeter for open and hydraulic ram
channels for flow measuring, nivelmeter
for heights measuring, pluviometer;
- central level, made of a the dispatcher for
receiving environmental parameters, the
software applications for administration
(introduction of information concerning the
technical state of substructure, other useful
information in risk management, alert
management) composed of a PC with
Windows 2003 Server, SQL Server 2005,
ArcGIS Server, CITYProtect database,
DISPECER application for receiving
environmental messages transmitted from
acquisition subsystem.
Data collected from the three sublevels are
used into an simulation software programme
along with other sublevel acquisition
parameters.
Acquisitioned data parameters are transmitted
through dispather application using GSM
infrastructure. Transmission data protocol is
GPRS.
34
Merasurement unit
Ultrasound sensor
Speed sensor
Pluviometer
Temperature sensor
Submersible sensor
Acquisition modul functions are: sensors
analogic semnals monitoring and analisys,
input numeric acquisition and monitoring
parameters,
numeric
output
activation(overfulfillment
alarm/prealarm
step signalling); distance data transmission
throught GSM/GPRS modem.
Software components for study, prognosis
and risk evaluation
Regarding high debits transit simulation on
Dambovita river, lake monitored parameters
are:
water
level,
defluent
debits,
rains(measured parametyer), affluent debits,
volumes (calculated parameter). Lake warter
volume for a specified given level is
determined from the volume lake curve
V F (z ) , given in parametri form in n
points ( Vi z i , i 1,....., n ):
where z is lake’s level at a given time,
measured by the sensor. For determining
lake’s affluent debit, it is used balance
equation between water volume entered and
left
from
the
lake:
"
'
2(V V )
'
"
Qaf" Qaf' (Qdef
Qdef
)
3600.t
On a current exploit – small and medium
affluent debits, there are no problems
regarding downstream flooding social and
economic places, where on high waters such
[problems can arise because Dambovita river
bed has a limited transport capacity especially
in Piata Unirii section, about 55,00 - 60,00
mc/s. Even at these debits water is deverted
in Izvor area banks and floods the street, as a
consequence of low river banks.
It has been observed that for maximum
affluent debits with overflowing probability
less than 1% it cannot be realised a sufficient
diminishing of high affluent debits, so as
maximum defluent debits to be engaged in
Dambovita river transport bed – which means
that flood risk in surrounding areas exists, in
upstream Unirii crossing, and also
downstream.
For achieving high debit transit simulation in
Bucharest it has been accounted 72
transversal profiles, of river bed located
between
Lacul Morii and N.H. Glina,
including hidrotechnic relevees nets, bridges
and undercrossing PiaĠa Unirii bridging, for a
distance covering 16.438 m.
Nepermanent motion estimation problem in
sewage systems is one of one of the most
difficult problems in hydraulics because this
has been conceived and functions as an
unitary system, with a double destination: to
undertake urban sewage water and meteoric
waters.
One problem which complicates network
functioning and hidraulic flowing model is
represented by the fact that in numerous
sections, collectors ramifies in flowing
meaning. This fact is benefic from the point
35
of overtaking debits from initial collector
because it descharges one each in two
branches, but on the other hand it can appear
difficulties
in
estimating,
even
aproximatively, of proportion in which debit
is distributed on both of the branches. The
network has in many places a ring form, and
mathematic modelation of flowing with a free
surface in these situations is extremely
difficult.
It has been defined 9 colectors named with
indicativesnamed: C1...C9. Each collector
has a number of injection points,
corresponding to a number of small collectors
which outlets through it and for every
injection point it has been evaluated due
hidrographic surface basin, in order to
evaluate rain water debit which will be
injected into the first point.
The calcul has been made with a specialised
software programme made by Catedra de
Hidraulica si Protectia Mediului from UTCB.
The
tp period of estimation rain was
considered equal with the time necessary for
a small drop of rain to reach, in free leakage
the farrest point of the hidrographic basin to
the estimation section, at which it is added
superficial flowing time.
For the gathering coeficcient, given large and
extra large collector dimensions, it has been
considerated a large gathering area and it has
been considered the value m=0.8.
For the under and along Dambovita river box,
debit injections has been of two cathegories:
Software programme hidraulic estimation
results
debits resulted from the 9 collectors
which flows into the box , has been
considered equal with that of estimation
debits from discharging sections of there
corrresponding collectors, considering
that the total hidrographic basin is
affected by rain.
Rain water debits corresponding to
hidrographic basins(smaller dimensions)
addiacente to the box, and which are
directly injected into the box through a
series of smaller collectors.
During software prigramme run following
has been achieved:
Uniform flowing model, regularly
used in estimation and dimension
results
for
sewage
network
parameters, it doesn’t reproduce the
exact situation. From comparing
parameters Q (ne-uniform movement)
and QPLIN (uniform movement),
exists high diferencies regarding
maximum
capacity
transport
estimation of different aduction
sections.
With few exceptions collectors have
normal form, telescopic, with growing
sections
in
flowing
meaning,
according with growing debit values,
such us, in the same meaning.
On the majority of collectors
maximum transport capacity evolution
does not have the same telescopic
evolution which is in its turn with
normal growing of of debits along
rivers flowing. This fact is owened to
ununiform slopes, but also influences
that exist between adiacent section
(there are cases when transport
capacity of a section can rise, but this
is blocked by the over pressure).
Over a numerous series of collectors
area sections on which slow growing
slopes alternates with big slopes. With
other words „existing fall” (level
geodezic difference) which is
considerabble represents an important
advantage, it is not used rationally. On
same sections speeds are limited and
exists the risk of clogs, on others
speeds are extremely high, motion
level is fast, it can be observer
hidraulic skip stepsin recording slow
movement regimes and exists the
danger of accentuated erosions.
In the following picture it is presented the
flowing aspect for the C1 colector.
36
From the picture it can be remarked that even
if the collector has sufficient transport
capacity it can be seen more than 6 sections
in which it can be realised hidraulic skip,
which determines flowing dificulties and
suplement pressure in some of the
corrresponding sections.
In the following picture it is analysed
transport capacity of the box for medium
flowing coeficients ĭ=0.4 si 0.8. it can be
easily remarced that in both situations
transport capacity of the box is exceeded.
Caseta
350
Q
300
Q
250
IRAM
200
Q-pl-0.4
150
Q-pl-0.8
100
50
0
1
21 41 61 81 101 121 141 161 181 201 221 241
Figure 3. Dambovita box transport capacity.
System’s database
Web portal solution
The system has a database made from two
components: relational database which
maintains information about sensors:
locations, read values, defects, contacts,
interesting points, roles etc and database
which maintains geodatabase information
system tables which are created and
administrated by ArcSDE schema, user
defined data sets, like “Feature Class”:
Feature Class with point geometry – sensors
equipments, Feature Class with line geometry
– streets, sewage system, evacuation routes,
Feature Class polygon geometry– flooded
areas, parkings, buildings, raster catalogues,
spatial information, GIS data attributes
realized with ESRI ArcCatalog product.
CITYProtect system software solution was
realised based on a web services solution. It
is an integrated solution developed for
studying interactive flood risk in a vulnerable
area in bucharest, based on scientific research
looking efficient exploit of water settlements
nearby Bucharest surroundings, and sewage
canal efficientization.
Monitoring system necessities regarding risk
prevention in pilot zone, imposed an intuitive
solution in order to present environment
parameters estimation results based on online supervision.
In this scope has been included GIS
functionalities appealable from within
CityProtect system and available on internet
37
through web services solution. It was defined
thematic maps (risk maps, hazard maps,
monitoring system elements positions, access
roads, interest points, in order to inform
population and to prevent evacuation.
CityProtect web solution represents an
information system for decisional support for
risk management in flooding in a monitorised
area. In this scope it is presented as a web
portal, with various information, textual or
graphical(including hazard maps) and various
facilities, available to the public or just
authorised persons (based on a username and
a password).
Portal (http://cityprotect.itc.ro) offers various
facilities:
- Public access information – legislative
reglementation,
good
practices,
survey, description, flooded streets
information,
- Monitorised area map (objectives,
avoiding routes), risk maps and
hazard maps regarding Bucharest
sewage system capacity, monitorised
area flooded streets
-
Canal flooding simulation (software
programme for mathematical
modelation),
-
Big water dischargement prognosis
(software
programme
for
mathematical modelation),
-
Risk flood management (alert
generation,
authorised persons
contacts in risk management)
On-line data acquisition monitoring
system (current values examination of
environment parameters in one of the
area located under observation,
historical defects showing)
Sensor location maps on a digital pilot
zone map. Web portal offers possibilities
of establishing roles and contacts, along
with reporting current or past alerts –
password restricted facilities.
-
-
Specialist information, accessible for
username and password, decisional
support,
specialists,
reports
(monitorised evolution parameters)
-
Preventive measures
Current flood risk management system
permits critical parameters detection and also
complex analysis on historical data sets
which can give a clear image over
deficiencies and evolution tendencies.
As an example of this system, consortium
execution specialists have interpreted data,
and elaborated following measures for
38
improving drain capacity of sewage canal in
Bucharest city:
smalll capacity in following localities:
Otopeni, Dobroesti, Tunari, Voluntari,
Stefanestii de Jos, Afumati, Ganeasa,
Pantelimon, Mogosoaia, Buftea,
Chitila, Chiajna, Rosu, Clinceni,
Bragadiru, Cornetu, Magurele, Jilava,
Popesti-Leordeni;
o Taking stricly sewage waters in periurban Bucharest’s area within
building two colectors along highway
belt, both starting in Otopeni bridge
area and finishing near Glina area:
Colector Otopeni – Tunari –
Voluntari – Pantelimon – Glina
with 25 km length and a pomping
station in Voluntari area can assure
sewage taking from: Otopeni,
Dobroesti,
Tunari,
Voluntari,
Stefanestii de Jos, Afumati,
Ganeasa Pantelimon;
Colector Otopeni – Chitila –
Chiajna – Clinceni – Magurele –
Jilava – Popesti-Leordeni – Glina,
with 39 km length and a pomping
station in Voluntari area can assure
sewage taking from:: Mogosoaia,
Buftea, Chitila, Chiajna, Rosu,
Clinceni, Bragadiru, Cornetu,
Magurele,
Jilava,
PopestiLeordeni;
5 Measures regarding develpment concepts
of metropolitan area:
o It neccessary a new approach in
driving all meteoric waters onto
Dambovita valley;
o Correlation of all opinions of
implicated
institutions
in
Bucharests development
and
nearby cities;
o Integrated disfunctions analisis;
6 Educational measures:
o apply the principle "the poluter
pays" in the situation of
unauthorised dischargement in the
sewage canal;
o growing the responsability level of
population through educational
measures
in
schools,
also
advertising means.
1. Current maintenance measures of sewage
canal:
systematical cleaning of collectors;
insufficient slopes colector decloging
replacement and mending of time aged
collectors in sewage systems canals;
2 Growing capacity measures of collectors
and transport of sewage canal
o In those places where colectors cannot
be replaced from various reasins , the
transport
capacity
can
be
supplemented by building some
braces at collectors having insufficient
capacity;
o Supplementing
current
transport
capacity with replacing existent
collectors with sections capable of
taking more debits.
3 Influent debit over taking measures in
sewage canal:
o diminishing water proof surfaces:
growing grass areas and permeable
surfaces;
imposing high permeable solutions
(permeable flagstones, grass areas,
permeable parking) in residential
development areas, supermarkets,
malls etc.;
o building retention basins; practically all
parking areas must have a retention basin
to assure taking at minimum ½ hours of
estimation rain, with 1/3 frequency, and
which to assure later dischargement with
a frequency of 1/3 and to later assure
volume dischargement in a minimum 24
hours period;
o growing numbers of parks and green
spaces.
4 Peri-urban area restrictive measures
regarding debits; has been analized two
types of measures:
o Avoid taking sewage waters in
Bucharest’s peri-urban area , solve
the problem at local level, using
18 stations of cleaning water with
39
Bibliography
[1]
[2]
[3]
[4]
[5]
Iamandi C., Petrescu V., Damian R.,
Sandu L., Anton Anton - Hidraulica
InstalaĠiilor , vol II, 2002, Bucureúti,
Editura Tehnică.
Cioc D., Anton A. ReĠele hidraulice:
calcul, optimizare, siguranĠă, 2001,
Editura
Orizonturi
Universitare,
Timiúoara.
E. Biltz – Proiectarea Canalizarilor –
Editura Tehnica Bucuresti, 1970.
TATU, G. – Hydraulic Transients
(english language). Lecture Notes, Civil
Engineering Institute of Bucharest,
1994.
Nix, S.J. – Urban Stormwater
Modelling and Simulation, CRC Press,
Inc., Boca Raton, Florida, 1994.
AR2-5.doc
RRA, Vol. XXI, Nr. 2, pag. 40-44, 2008
Printed in Romania
WEB-BASED MEDIATION SYSTEM FOR POORLY DEVELOPED
ECONOMIC AREAS
Alexandru BOTU, Senior Researcher, IPA SA
Adrian BADOIU, Senior Researcher, IPA SA
Sanda PETRESCU, Senior Researcher, IPA SA
Vasilica VLAD, Senior Researcher, IPA SA
Gheorghe MATEI, Senior Researcher, IPA SA
Abstract: The project is aimed to create an IT system accessible via Internet to take over and to publish
both the supply and demand of products and services available in the household, to mediate between the
supply and demand of the home labor force, to stimulate the initiative by presenting in detail on-line
business opportunities. All these actions are meant to stimulate the regional development.
The system addresses the areas with reduced economic development, characterized by a high
unemployment rate and special social problems, but it can also be implemented in other parts of the
country, for regional sustainable development. The pilot IT system resulting from this project will be
implemented in Targu-Carbunesti area , Gorj County.
Keywords: information system, mediation system, match algorithm
1. Introduction
2. System Architecture
The project sets as goal to create an IT
system accessible via Internet, that is meant
to take over and to publish data regarding
the supply and demand of products and
services available in the household and to
mediate between the supply and demand of
the home labor force. The project illustrates
the support that the ITC brings in the
sustainable regional development of the poor
areas, how it can stimulate the initiative by
presenting on-line business opportunities
and means.
The system is accessible via Internet and it
comprises hardware and telecommunications
open infrastructure, interconnected databases
of the City Halls, the County Agency for
Labor Force and the County Chamber for
Commerce
and
Industry,
software
applications using web technologies,
Internet portal to deliver mediation and
information services for citizens and
business environment.
The pilot system will deliver services for 10
local communities in the vicinity of Targu
Carbunesti – Gorj area. The beneficiary is
Targu Carbunesti City Hall, who will
maintain the system in the post project phase
by a private-public partnership.
The system architecture follows the system
main functions. The structure consists of a
central system placed at the Târgu Cărbuneúti
City Hall, and local systems placed at the City
Halls of the villages in the surrounding area.
In figure 1 is presented the system general
structure.
Figure 1. System general structure
41
The central system has the following main
modules: a module to take over and store
announcements, a module for automated
transmission by email of the announcements
to interested persons, communication module,
announcements management module and the
web portal.
An announcement belongs to one of the
following categories: offers /requests of
employment
(permanent, occasional,
seasonal); offers/ requests of services; offers/
requests of products; offers/ requests of
association for starting up new business.
As hardware, the central system structure
consists of a data server, an application and
web server, a workstation with info kiosk
functionality,
connection elements. As
software, the central system contains:
database and database management server,
dedicated
software
application,
communication software, web server.
The local system comprises a module for
taking over and store announcements, a
communication module and a module for the
management of the announcements.
All the above mentioned
systems are
permanently connected to Internet.
The software applications were developed in
innovative technologies as PHP for the
dynamic part of the applications, XML and
SOAP for communication within system,
HTML for static pages and CSS for layout
control. The Apache platform was used as
web server.
2. System Main functions
The system functionality is a complex one
and its main functions are enumerated
bellow. It has to take over, to store and to
publish the supply and the request of home
labor force, to take over, to store and to
publish the offer and the request of products
and services available in the household and
also to take over, to store and to publish the
requests/ offers for association in starting a
business.
The system includes a centralized database
running on the central server in which are
recorded all the announcements posted into
the system by various ways.
The system is announcement oriented and
provides adequate user interfaces for on-line
recording of the requests/offers.
Basically the data is recorded into the system
either via the workstations placed at the local
City Hall premises or via any computer
connected to Internet.
The input data flow is the following:
- The announcements posted at the
workstations are stored into the local City
Hall databases, then they are transferred
automatically using web services over
Internet and finally they are stored into the
database of the central server.
- The announcements posted via Internet
from other computers are directly stored
into the central server database.
- The data originating from the County
Agency for Labor Force and the County
Chamber for Commerce and Industry are
automatically transferred over Internet and
stored into the central database.
The output data flow is as following:
- Any Internet user can visualize all the
updated data stored into the central
database by accessing the system web
portal.
- The central server sends messages
periodically to the City Hall workstations,
structured on categories of announcement;
the messages are sent over Internet using
web services.
- The messages received from the central
server at the local stations are stored and
published on the local server.
- The software application running on the
City Hall workstations manages both the
announcement originating / addressed to
persons living in the respective Hall
jurisdiction as well as all the other
available announcements.
The core of the system is an Internet portal
which provides:
- on-line forms to introduce requests/offers
of products, services, labour
- an engine to meet the requests and offers
posted within the portal and to perform the
match algorithm
42
- real time data about the situation at local
level (by means of rapid answers to search
requests, grouped on request type)
- database with data regarding the existing
requests and offers and the needs of local
companies and communities.
application uses for determining a qualitative
match degree, on a scale running from perfect
to acceptable.
3. Match algorithm
The match algorithm is based on the common
ontology used at defining a request,
respectively an offer.
More common
ontology increase the possibility of successful
matching between request and offer. The
method to increase the chance of success is to
use common selection lists for introducing a
request or an offer.
In the case of a labour announcement, the
announcement structure mandatory comprises
common elements as: labour field,
educational level, job type by time schedule,
county. The possible values to be selected
from lists are identical for both request and
offer type. The same principle is employed in
the case of product/ services announcements.
In their structure the fields product/ service
code and county are always completed. All
these fields represent the criteria that the
The on-line forms to be completed by users
are designed to enable this unique ontology
within the system.
There are used
exclusively selection lists (drop-down) with
one or multiple choice and official classified
lists (CAEN, CPSA, etc). Exceptions are only
users’ personal data fields.
Based on the results of the matching
algorithms the application determines:
which messages will be transmitted
to whom these messages will be
transmitted
on which channels the messages will
be transmitted (e-mail. webservices,
data direct display)
The application extracts every announcement
registered into the database and analyzes it.
The field announcement_type specifies if the
announcement is a request or an offer while
the object field specifies if it refers to labour
or products/services market.
The five possible situations to occur are
presented in Table 1:
Category
1
2
3
4
Field announcement_type value
request
request
offer
offer
Field object value
lm
ps
lm
ps
5
proposal
af
Significance
labour request
product/services request
labour offer
product/services
offer
business proposal
Table 1. Match categories
For each situation the application runs a
match
algorithm.
For
the
current
announcement, extracted from the database,
will be extracted and analyzed all the
complementary announcements (category 1
complementary with category 3, category 2
complementary with category 4). For
category 5 the algorithm will search the
match inside the category, based on activity
field.
For each resulted match the application
extracts the contact data of the user who
posted the announcement . If the
announcement was posted from a local
station, the matched announcements are
transmitted to the respective workstation via
web services.
If the announcement was posted from a
computer connected to Internet the matched
announcements are transmitted via email.
43
4. System Data Sources and
Communications
The possible sources for system database are:
citizen, business entities, non governmental
associations and organizations, local public
administration units, County Agency for
Labor Force, County Chamber for Commerce
and Industry, any other entity accepted into
the system.
The points in which the data may be loaded
into the system are the City Halls
workstations, the web portal and the web
services in the case of the stakeholders with a
permanent role into the system.
The announcements posted by the users are
taken over and checked by the system from
the point of view of correctness and
completeness. Then they are processed in
view of increasing the system protection at
malevolent attacks by elimination of special
characters, tags or code sequences.
The verified and processed data are then
coherently stored into the database of the
Central system.
Now data is available for the next actions:
local and by Internet visualization, matching
of the offers and requests, the transmission by
means of the web services of the freshly
arrived announcements to the local
workstations
where
the
“match”
announcement was posted, the automated
transmission by email to the registered users
of the announcements that “match” with the
users expectations.
The communications have a crucial role in
the system – the announcements match
algorithms and the communications are
actually the very essence of the system
functionality.
In figure 2, 3 and 4 are presented several
application captured screens that illustrate the
above features.
Fig.2. Project Main page
Fig. 3.User announcement posting page
44
Figure 4. Match procedure. Automated email transmission
5. Conclusions
The project implementation will bring
benefits for the focused area. Among the
expected benefits we can mention: increased
opportunities for bussines start and
deployment, increased opportunities for
employment, contribution to the city and
surrounding
localities
sousteanable
development, better and more transparent
relations public authority – citizen, better
implication of the citizen in community’s
economic, social, cultural life, the
generalization of the IT use in the day-to-day
life of the local communities
References
[1] E.F. Codd - A relational Model of Data
for
Large
Shared
Databank.
http://www.acm.org/classics/nov95/toc.html
[2]
J.D. Ullman - Principles of database
Systems –Galgotia Publishing, 1994
[3] J.D. Ullman - The Database Approach to
Knowledge
Representation
http://dbpubs.stanford.edu:8090/pub/showDo
c.Fulltext?lang=en&doc=199638&format=pdf&compression
The information system, which represents the
main result of the project,
will be
administered in the post project phase by a
local private-public partnership including the
City Hall of Târgu Cărbuneúti and the
representatives of the local business media.
AR2-6.doc
From: Newsletter IFAC nr. 2 April 2008
Preliminary Leaflet
ACADEMIA
ROMÂNĂ
Encouraged by: The European Commission
The 2-nd EUROPEAN CONFERENCE
on
APPLICATION, INTEGRATION, CONTROL, MODELLING,
TESTING, and INTELLIGENT CONTROL and INTELLIGENT
MODELLING, OF THE FUEL CELLS and H2 APPLICATIONS and
THEIRS ECONOMIC / ENVIRONMENT CONSEQUENCES:
eHYDROGENIA ©
H2_FUEL_CELLS_MILLENIUM _ CONVERGENCE
September 22-23,
2008, Bucharest, ROMANIA, http://www.ipa.ro/html/evenimente.html
ACADEMIA ROMÂNĂ, AULA MAGNA, calea Victoriei 125
ACADEMIA ROMÂNĂ, and IPA SA, Bucharest.
Founded, or organized or encouraged, or in part supported by
ROMANIAN
ACADEMY
IPA SA
Calea Victoriei 125, Bucharest
www.academiaromana.ro
Calea Floreasca 169, Bucharest
www.ipa.ro
supported by
MECT
MINISTRY OF EDUCATION, RESEARCH and YOUTH, ROMANIA
achieved also with the participation of the
THE INSTITUTE FOR ENERGY RESEARCH, Fuel
Cells Forschungszentrum Jülich, Germany,
HAMBURG UNIVERSITY OF APPLIED SCIENCES, Fuel Cell Lab, Hamburg Germany
ASE
ICI
ACADEMY for ECONOMIC STUDIES
NATIONAL INSTITUTE FOR R&D IN INFORMATICS
www.acad.ro
ICPE
POLITEHNICA
www.ici.ro
INCDIE ICPE- CA
ICSI, Research Institute, Râmnicu Vâlcea
ROMANIAN ALLIANCE FOR HYDROGEN AND FCs.
UNIVERSITY
UPB , Bucharest
UE-Bucharest
and with the encouragements and participation of:
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
46
ECOLOGY
UNIVERSITY
ROMANIAN ACADEMY,
MED-ANCS, MINISTRY OF EDUCATION and RESEARCH, ROMANIA,
The INSTITUTE FOR ENERGY RESEARCH - FUEL CELLS, Forschungszentrum Jülich, Germany,
Hamburg University of Applied Sciences, Fuel Cell Lab
IPA SA, research entity, Bucharest,
Romanian Alliance for Hydrogen and FCs,
ICSI, Râmnicu Vâlcea, and Hydrogen Platform from ICSI Râmnicu Vâlcea,
INCDIE ICPE –CA, Advanced Researches, Bucharest
ICPE, Bucharest,
ICEMENERG, Bucharest,
ICI, Bucharest,
UPB – University Politechnica Bucharest
Faculty of Electronics and IT&C Technology of UNIVERSITY “POLITEHNICA “ Bucharest,
Faculty of Automation Engineering & Computers of UNIVERSITY “POLITEHNICA” Bucharest,
Faculty of Energy of UNIVERSITY “POLITEHNICA “ Bucharest,
SC OVM ICPPET SA
;
University of Bucharest, and University of Bucharest Faculty of Chemistry,
Ecology University, Bucharest,
Hynergreen Technologies S.A. Spain,
Chamber of Commerce and Industry, Romania, Chamber of Commerce, Industry and Agriculture, Giurgiu, and many other initiatives and projects.
;
;
;
;
The creation of Consortia and Projects BROKERAGES.
PROPOSED
ORGANIZING COMMITTEE:
FIRST HONORIFIC CONFERENCE CHAIRS
Detlef STOLTEN
Florin FILIP
Florian UDRESCU
,
Univ. Prof. Dr. ,
Director of the Institute
for Energy Research-Fuel Cells.
Vice-President of Romanian Academy
Principal Scientist, General Manager
IPA SA
John F. ELTER,
Jülich, Germany
PhD, Consultant, PlugPower, USA
HONORIFIC CONFERENCE CO-CHAIRS:
HONORIFIC CONFERENCE CO-CHAIRS:
Wolfgang WINKLER,
Gleb DRĂGAN
University Professor Dr., Hamburg University, Germany
Academician, Romanian Academy
Tapani MIKKELY
Ecaterina ANDRONESCU
European Commission
Univ. Prof. Dr. Eng. UPB Bucharest
Crisitian PREDESCU,
Ion Gh. ROSCA, Univ. Prof. Dr,
Univ. Prof. Dr. Eng. , Politehnica University Bucharest
RECTOR of ASE, Bucharest
Rosalie ZOBEL , Ph.D
Anton ANTON,
Director of the IST Programme. European Commission
University Professor Dr. Eng., MED-ANCS, Romania
Mihai CARAMIHAI, First Research Scientist,
Nicolae VASILIU
Univ. Professor Dr. Ing. , POLITEHNICA University Bucharest
University Prof. Dr. Eng., Politehnica University, Bucharest
Ulrich SCHMIDTCHEN
Stephan PASCALL
German Hydrogen and Fuel Cell Association (DWV)
Adviser, European Commission
Ioan DUMITRACHE,
Mircea DUğU
Univ. Professor Dr. , Member Corresp. of Romanian Academy
Univ. Prof. Dr, RECTOR of UE-B, Bucharest,
Silviu Dorian CHELARU,
Dumitru MIRON, University Prof.. Dr. ,
IPA SA, Electrolyzers Trends
ASE, Academy of Economic Studies
Prof. Dr. Fiz. Wilhelm KAPPEL
Director General, INCDIE ICPE-CA, Advanced Researches
Paul PENCIOIU,
Principal Scientist, Ph. D. Candidate, Scientific Director of ICPE,
Mariana ILIESCU
Principal Research Scientist, ICSI Râmnicu Vâlcea
Ing. Elena ENESCU
Vice -Director , INCDIE ICPE-CA, Advanced Researches
Alexandru STRENC
Ph.D. Eng., Scientific Director of the State Patents and Trade Marks Office, Romania
Dan Alexandru STOICHESCU
Univ. Professor Dr. , UPB, Bucharest
Dan TEODOREANU,
Ph.D., Principal Research Scientist , ICPE, Bucharest,
Mihai CULCER,
Ph.D. , Principal Research Scientist, ICSI Râmnicu Vâlcea
Dong-Ryul SHIN
Advanced Fuel Cell Research Center, Korea
Ion STAMATIN, Univ. Prof. Dr.
University of Bucharest & Romanian Alliance for Hydrogen and FCs.
Jens KRUG
SMA Technologies AG, Germany
Gabriel VLADUT
Principal Research Scientist, SC IPA, Director IPA CIFAT
Ioan ùTEFĂNESCU
University Professor Dr. , Director of ICSI Râmnicu Vâlcea
Mariana BISTRAN
Principal Research Scientist, IPA SA, Conference Co-Founder
Vasile STANCIU,
Ph. D., Principal Research Scientist, ICSI Râmnicu Vâlcea
Dr. -Ing. Rolf BLATTNER,
Forschungszentrum Karlsruhe GmbH
Peter LOFFLER
EU Commission, IEEA
Camelia CAMAùOIU
Univ. Professor Dr. , Prorector of UE-B
Radu DOBRESCU, Univ.Prof. Dr. Eng.
POLITEHNICA University Bucharest
Jochen STRAUB
Ballard GmbH, Germany
Elisabeta Pasculete
Ph.D., SC OVM ICPPET SA
E.V.ROSA,
Hynergreen Technologies SA, Spain,
Aessandro DELFRATE
UHDENORA SPA Italy
Dan POPESCU Univ. Professor Dr. Eng.
Politehnic University, Bucharest
CONFERENCE’S FOUNDER and CHAIR:
Gheorghe Mincu SĂNDULESCU,
Florin FILIP,
University Prof., Dr. Eng., First Research Scientist,
Director for Advanced Researches, IPA SA & UE-B , Bucharest,
Member Corresp. of the European Academy of Sciences.
Vice-president
ROMANIAN ACADEMY
[email protected]
Mariana BISTRAN, Principal Research Scientist, Diplom. Eng. IPA SA,
47
ORGANIZATORIC CHAIR
Monica VISU, IPA SA
CONFERENCE GOALS
To provide a forum for the presentation, discussion, dissemination and generation of new
and favourable ideas in the fields of the
APPLICATION, INTEGRATION, CONTROL, MODELLING, TESTING
and
INTELLIGENT CONTROL and INTELLIGENT MODELLING
OF THE FUEL CELLS AND OF THE H2 APPLICATIONS.
To add steps in advance in the fields of hydrogen and fuel cells researches, studies,
developments and successfully integration,
To add scientific contributions in the speeding the accomplishment of successes in above,
very important scientific and technical fields.
To add contributions ant the speeding of the implementation of the Hydrogen Economy.
To contribute at the European sustainable growing of the fuel cells and H2 applications and
developments,
To encourage European Research, especially inside the frames of the European Commission,
in the fields of
the APPLICATION, INTEGRATION, CONTROL, MODELLING, TESTING and
INTELLLIGENT CONTROL and INTELLIGENT MODELLING OF FUEL CELLS.
To create projects, projects proposals and European research consortia.
To contribute at the generation of the efficient consortia and proposals of projects, in the
Conference’s fields. To contribute at ERA activities and results in the Fuel cells applications
and developments.
To add important influences at the dissemination, awareness creation and correct
information of and responses from the stakeholders and end-users.
The creation of Consortia and Projects BROKERAGES.
Conference Language
The official language of the event is English.
Conference Location
The conference will be held in Bucharest, the city that was mentioned, in the year 1459, in the
official papers of Vlad Tepes Voivode (named also Dracula) and where the very important, country
Voivode (Voievod ) Dracula, was referred to as an efficient trade developer, and an interesting
commercial rules analyst.
Bucharest is at half distance between the Carpathians and the Black Sea, and offers splendid
sightseeing opportunities and climate. September is one of the most pleasant and beautiful month
of the year in Bucharest.
48
Conference Venue
Academia Romană , AULA MAGNA, calea Victoriei 125, Bucharest. Registration Desk at the entry
of AULA MAGNA Hall.
Important aspects and dates:
x Submission of Papers:
dead - line
1 September 2008
x All received in due time and accepted papers will be automatically typed, in the
preprints, without any obligations from the part of the Conference organizers,
x Papers should be sent by e-mail to: [email protected] or to [email protected]
respective to
Organizatoric Chair: Monica Visu. Bucharest, IPA SA, Calea Floreasca 169, Postal Code 014459
[email protected]
Conference Proceedings:
The Conference Proceedings will include, without any obligations from the organizers part, and
without other information to the elaborators of papers, the accepted papers. Each paper is
necessary to not surpass 10 pages (A4).
Registration fee
* Registration: Euro 200 (free registration for students and teachers, based on relevant documents/ student card).
On-line pre-registration:
;
;
http://www.ipa.ro/h2fuel/prereg.html (Ctrl+click to follow the hiperlink)
Transport to Bucharest and accommodation are not included in the conference fee. ,
The fee (referring only to paid registration), includes the possibilities of participation at the all sections and at scientific
and at the social activities of the Conference, the bag with preprints and possible annexes, refreshmen and participation at
Conference’s Cocktails.
____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
Notes:
1.The firms symbols and names, for instance Microsoft ® , are object of registration of the respective firms or entities.
2. The words combination:
H2_FUEL_CELLS_MILENIUM _CONVERGENCE …
and the word
HYDROGENIA
©.
are object of registration of IPA SA Bucharest and of Romanian Academy and of
3. The presentation of the symbols of EU Commission do not imply any obligations from the part of these entities, nor does involve any responsibility on their part.
4.The indicated projects, presented in this leaflet, are achieved with the support from the European Commission or of MECT Romania.
5. The content of cited projects, or of materials, or of this leaflet does not necessarily reflect the position of the European Community, nor does involve any responsibility on their
part, nor from the organizers part, nor from other part or entity.
Edited and printed by
IPA SA PUBLISHING HOUSE
of IPA SA Bucharest, 2008
49
Conference encouraged by: The European Commission
eBSN
The European eBusiness Support network
http://ec.europa.eu/enterprise/e-bsn/index_en.html
ANPCDEFP Romania
AGENTIA NATIONALA PENTRU PROGRAME COMUNITARE IN DOMENIUL EDUCATIEI SI
FORMARII PROFESIONALE. PROGRAMUL LEONARDO da VINCI 9-th EUROPEAN CONFERENCE
on
E-BUSINESS/ E-COMMERCE/
E-LEARNING/ E-WORK/ E-GOVERNMENT/ E-DEMOCRACY/ EHEALTH/ E-MEDIARY, E-INCLUSION / BB-BROAD-BAND, ON-LINE
SERVICES / E-MARINE / E-BANKING,
ADAPTNETICS,
AND THEIR INFLUENCES ON THE ECONOMIC/ SOCIAL
ENVIRONMENT AND CONTRIBUTIONS TO ERA
E-COMM-LINE 2008
September 25-26, 2008, Bucharest, ROMANIA, ASE Piata Romana 6
Founded, organized and in part supported by
IPA SA
ASE
RESEARCH INSTITUTE
ACADEMY for ECONOMIC STUDIES
Bucharest
www.ipa.ro
Bucharest
www.ase.ro
supported by
MED-ANCS
MINISTRY OF EDUCATION and RESEARCH, ROMANIA
achieved with the participation of the
ROMANIAN ACADEMY
ICI
NATIONAL INSTITUTE FOR R&D IN INFORMATICS
www.acad.ro
UPB University
Bucharest
Bucharest
50
www.ici.ro
MARITIME
ECOLOGIC UNIVERSITY
UNIVERSITY of Constanta
www.pub.ro
www.umc.ro
www.ueb.ro
With the participation of:
;
;
;
;
;
;
;
;
;
;
;
;
;
ROMANIAN ACADEMY, and The Commission of Economic Cybernetics of Romanian Academy
eBSN THE EUROPEAN e-BUSINESS SUPORT NETWORK,
NATIONAL INSTITUTE FOR R&D IN INFORMATICS, ICI, BUCHAREST,
AGENTIA NATIONALA PENTRU PROGRAME COMUNITARE IN DOMENIUL EDUCATIEI SI FORMARII
PROFESIONALE. PROGRAMUL LEONARDO da VINCI
CHAMBER OF COMMERCE AND INDUSTRY OF ROMANIA AND BUCHAREST MUNICIPALITY,
INSTITUTE FOR COMPUTERS TECHNIQUES ITC – BUCHAREST
POLITEHNICA University, Bucharest
Faculty of Electronics and IT&C Technology of UNIVERSITY “POLITEHNICA “ Bucharest
Faculty of Automation Engineering & Computers of UNIVERSITY “POLITEHNICA” Bucharest
Faculty of Finances and Banks of THE ECOLOGY UNIVERSITY Bucharest,
ECOLOGY UNIVERSITY,
Research Institute for Artificial Intelligence, Romanian Academy.
Chamber of Commerce, Industry and Agriculture, Giurgiu, and many initiatives and projects such as:
Training of the Trainers, IDEAL-IST, CORA, RoDI-IST-NET PROJECTS BROKERAGE.,
Projects: ESTELLA, eMarine, eEmployment and others
Creation of Consortia and BROKERAGE Event for the European Commission Financed
Projects and for other Research Projects
Encouraged also by
ANISP- National Soc. of the Internet Service Providers, Romania,
Sponsors:
MICROSOFT ®, Romania,
PROPOSED ORGANIZING COMMITTEE
HONORIFIC CONFERENCE CHAIR:
HONORIFIC CONFERENCE CHAIR:
Florian UDRESCU, Principal Research Scientist,
General Manager, IPA SA, Research Institute
Ion Gh. ROSCA, Univ. Prof. Dr, RECTOR of ASE,
The Academy of Economic Studies
HONORIFIC CONFERENCE VICE-CHAIRS:
HONORIFIC CONFERENCE VICE-CHAIRS:
Florin FILIP,
Ion STANCU,
Univ. Prof. Dr, PRO-RECTOR of ASE
Vice-President of Romanian Academy
Doina BANCIU, Univ.Prof. Dr,
Josef GRICAR,
ICI and University Bucharest,
Univ. Professor and Director, Universiy of Maribor , Slovenia
Rosalie ZOBEL , Ph.D
Director of the IST Programme. European Commission
Advisor, European Commission
Stephan PASCALL,
Costas ANDROPOULOS,
Ion DUMITRACHE, Univ.Prof. Dr.
Head of Unit , European Commission
Tapani MIKKELI,
Head of Unit , European Commission
Dorin JULA, Univ. Prof. Dr.
Ecology University Bucharest.
Mihai CARAMIHAI, First Research Scientist,
Univ. Professor, Ph.D., POLITEHNICA University Bucharest
Dumitru MIRON, University Prof.. Dr. ,
Iordana ELEPHTERIADOU
Francesco NACHIRA, European Commission
Iordan PETRESCU, Univ. Prof. Dr.
Principal Administrator, Coordinator of the eBSN Network,
EU Commission
Silviu HOTARAN, Manager, Microsoft East Europa
Gabriel VLĂDUЭ
Director IPA CV, Craiova, Romania
Dan POPESCU , University Professor Dr. Eng.
CONFERENCE VICE-CHAIR
ASE, Academy of Economic Studies
UCB- Bucharest
Doina CARP, Prorector
Maritime University Constanta
Iulia MIHAIL,
Director, MED-ANCS, Romania
51
Constanta-Nicoleta BODEA,
Camelia CAMASOIU , Univ.Prof. Dr.
Prorector of the UE-B University , Bucharest
Univ.Prof. Dr.
Director for Research , ASE University, Bucharest
Paul TIMMERS, Director of the IST Programme:
Silviu HOTARAN,
General Manager
Microsoft Romania
eInclusion, European Commission
Andreea OLTEANU
Radu DOBRESCU, Univ.Prof. Dr.
Eng.
Projects Expert, Leonardo da Vinci Programme
Bogdan GHILIC, Univ.Prof. Dr.
Joan Rodon Mòdol, ESADE, Spain
ASE , Bucharest
CONFERENCE VICE_CHAIR
Camelia DOGARU,
IT activity coordinator, ISTC delegate
Dan Alexandru STOICHESCU Univ. Professor Dr. Eng.,
Politehnica Univesity Bucharest
CONFERENCE FOUNDER and CHAIR:
CONFERENCE FOUNDER and CHAIR:
Gheorghe Mincu SANDULESCU,
Radu STROE,
University Professor Dr.,
First Research Scientist,
Director for Adavnced Researches
Member Corresp. of the European Academy of Sciences,
University Professor Dr.,
Academy of Economic Studies,
President of the Commission for Economic Cybernetics of Romanian
Academy
CONFERENCE FOUNDER and CHAIR
Mariana BISTRAN, Principal Research Scientist
IPA SA , Bucharest
ORGANIZATORIC CHAIR
Monica VISU
SC IPA SA
CONFERENCE GOALS
To provide a forum for the presentation, discussion and generation of new and favourable
ideas in the fields of the latest viable, practical and scientific developments in e-Activities:
e-Business, e-Learning, and also
e-Commerce, Mobile e-Commerce / Mobile e-Business / Mobile e-Banking / e-Europe,
e-Payments, e-Procurement, e-Marketplaces, New Working Environment, e-Banking / Telebanking, e-Administration, On-Line Services, Mobile e-Learning, e-Work, eInclusion e-Health, e-Government, e-Marine, Applications of the Broad Band
Communications, Adaptnetics, Virtual Institutes and Standardization in the e-Fields.
To contribute at the e-Learning development and promotion including through the session:
THE e-LEARNING PRACTICING IN THE VOCATIONAL E&T ,
under the coordination of the Leonardo da Vinci Programme.
To achieve BROKERAGES for project proposals/ consortia:
IDEALIST, CORA and RoDI - IST – Net and others.
To contribute to the e-Europe and to e-Europe+ programs and to make effective scientific
connections in the e-fields through e-World.
52
To encourage the Training of the Trainers; to encourage the training of the learners.
To contribute to the improvement of the economic and business environment through
e-Activities.
eMarine Section.
Conference Language
The official language of the event is English.
Training, learning and presentations within parallel Workshops will be achieved in Romanian
Language.
Conference Location
The conference will be held in Bucharest, the city that was mentioned for the first time in the year
1459, in the official papers of Vlad Tepes Voivode (named also Dracula) and where the very
important, country Voivode (Voievod ) Dracula, was referred to as an efficient trade developer, a
good commerce man and an interesting commercial rules analyst.
Bucharest is at half distance between the Carpathians and the Black Sea, and offers splendid
sightseeing opportunities and climate. September is one of the most pleasant and beautiful month
of the year in Bucharest.
Conference Venue
ASE - Academy of Economic Studies, BUCHAREST, Piata Romana 6, AULA MAGNA in the Big
Historic Hall (an architectural patrimony and masterpiece) and "Madgearu" Hall.
Registration Desk at the entry of AULA MAGNA Hall.
Important aspects and dates:
x Submission of Papers: deadline 1 September 2008
x All received in due time and accepted papers will be automatically edited, in the
preprints, without any obligations from the part of the Conference organizers,
x Papers should be sent by e-mail in attention to Monica Visu Organizatoric Chair:
[email protected] sau mvisu@ipa.
Conference Proceedings:
The Conference Proceedings will include the accepted papers, maximum 8 pages (A4) per each paper.
Here (ctrl+click to follow the hyperlink) you can find the model for presentations
Registration fee
* Registration: Euro 200 (free registration for students and teachers, based on relevant documents/ student card. Other
discounts and free registration possibilities).
http://www.ipa.ro/e2008/prereg.html (Ctrl+click to follow the hiperlink)
On-line pre-registration:
;
Transport to Bucharest and accommodation are not included in the conference fee.
;
The fee (referring only to paid registration), includes the possibilities of participation at the all sections and at scientific
and at three social activities of the Conference, the bag with preprints and possibly annexes, refreshments and entry at
about 3 Meetings Cocktails.
http://www.ipa.ro/e2008/Leaflet_04_04_2008.doc
____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
Notes:
1.The firms symbols and names, for instance Microsoft ® , are object of registration of the respective firms or entities.
2. The words combination: E_COMM_LINE_200x… ,
Adapnetics are object of registration of IPA SA & ASE Bucharest,
3. The presentation of the symbols of EU Commission, eBSN, Leonardo da Vinci Programme do not imply any obligations from the part of these entities, nor
does involve any responsibility on their part.
4.The indicated projects, presented in this leaflet, are achieved with the support from the European Commission.
5. The content of cited projects, or of materials, or of this leaflet does not necessarily reflect the position of the European Community or of the National
Agency Leonardo da Vinci, nor does involve any responsibility on their part.
Edited and printed by IPA SA PUBLISHING HOUSE of IPA SA Bucharest
53

5(9,67$ 520Â1 `( $8720$7,&amp

Transcription

Similar documents

Bucharest City Romania

Phoenix Logistics Center

Spring 2013 - ipa region 15

conference engleza_Layout 1

The Metro System of Bucharest city

The High Octane Entertainer

12th annual raigam : a glittering show honours

U N I V E R S I T Y O F A G R O N O M I C

www.corturisiprelate.ro - CCSM Corturi Industriale