An Advanced Engineering Framework experimented on a R&AE Electric Vehicle case

International audienceThis article describes modeling activity experimented on an Advanced engineering case of Zero Emission Vehicles at Renault. A key advantage of our approach is that system architecture and requirements management at all the stages of the system life cycle are managed in a unique data model and unique database. It reviews conceptualization and production process of a complex system. It presents a spectrum of activity modeling techniques, ranging from a widely used systems engineering diagram, to continuous flow modeling. The techniques include use case definition, requirements elicitation, system architecture definition and finally Electric and Electronic architecture. The article also describes refinements of modeling activity using arKItect© tool

Object Oriented Database Management Systems-Concepts, Advantages, Limitations and Comparative Study with Relational Database Management Systems

Object Oriented Databases stores data in the form of objects. An Object is something uniquely identifiable which models a real world entity and has got state and behaviour. In Object Oriented based Databases capabilities of Object based paradigm for Programming and databases are combined due remove the limitations of Relational databases and on the demand of some advanced applications. In this paper, need of Object database, approaches for Object database implementation, requirements for database to an Object database, Perspectives of Object database, architecture approaches for Object databases, the achievements and weakness of Object Databases and comparison with relational database are discussed

Record Subtyping in Flexible Relations by means of Attribute Dependencies

The model of flexible relations supports heterogeneous sets of tuples in a strongly typed way. The elegance of the standard relational model is preserved by using a single, generic scheme constructor.In each model supporting structural variants the shape of some part of a heterogeneous scheme may be determined by the contents of some other part of the scheme. We formalize this relationship by a certain kind of integrity constraint we have called "attribute dependency" (AD). We motivate how ADs can be used, besides their application in type and integrity checking, to incorporate record subtyping into our extended relational model Moreover, we show that ADs yield a stronger assertion than the traditional record subtyping rule as they consider interdependencies among refinements. We discuss how ADs are related to query processing and how they may help to identify redundant operations

Incorporating record subtyping into a relational data model

Most of the current proposals for new data models support the construction of heterogeneous sets. One of the major challenges for such data models is to provide strong typing in the presence of heterogenity. Therefore the inclusion of as much as possible information concerning legal structural variants is needed. We argue that the shape of some part of a heterogeneous scheme is often determined by the contents of some other part of the scheme. This relationship can be formalized by a certain type of integrity constraint we have called attribute dependency. Attribute dependencies combine the expressive power of general sums with a notation that fits into relational models. We show that attribute dependencies can be used, besides their application in type and integrity checking, to incorporate record subtyping into a relational model. Moreover, the notion of attribute dependency yields a stronger assertion than the traditional record subtyping rule as it considers some refinements to be caused by others. To examine the differences between attribute dependencies and traditional record subtyping and to be able to predict how attribute dependencies behave under transformations like query language operations we develop an axiom system for their derivation and prove it to be sound and complete. We further investigate the interaction between functional and attribute dependencies and examine an extended axiom system capturing both forms of dependencies

Object Oriented Database Management Systems-Concepts, Advantages, Limitations and Comparative Study with Relational Database Management Systems

Object Oriented Databases stores data in the form of objects. An Object is something uniquely identifiable which models a real world entity and has got state and behaviour. In Object Oriented based Databases capabilities of Object based paradigm for Programming and databases are combined due remove the limitations of Relational databases and on the demand of some advanced applications. In this paper, need of Object database, approaches for Object database implementation, requirements for database to an Object database, Perspectives of Object database, architecture approaches for Object databases, the achievements and weakness of Object Databases and comparison with relational database are discussed

Object-relational spatio-temporal databases

We present an object-relational model for uniform handling of dimensional data. Spatial, temporal, spatio-temporal and ordinary data are special cases of dimensional data. The said uniformity is achieved through the concept of dimension alignment, which automatically allows lower dimensional data and queries to be used in a higher dimensional context;Unlike ordinary data, dimensional objects are interwoven. We introduce object identity (oid) fragments to circumvent data redundancy at logical level. Computed types are placed appropriately in a type hierarchy to allow maximal use of existing methods. A query language for spatio-temporal data is presented for associative navigation. A framework for algebraic optimization of the query language is suggested;A pattern matching language is designed for complex querying of spatio-temporal data which seamlessly extends the associative navigation in our query language. The pattern matching language recognizes special features of time and space providing an appropriate level of abstraction for application development compared to traditional languages. This reduces the need for embedding the query language in a lower level language such as C++. The pattern matching language is also dimensionally extensible. The pattern matching allows query of data with multiple granularities and continuous data. It also provides hooks for direct query of scientific data (observations);Our model is dimensionally extensible, and also an extension of a relational model for dimensional data. Moreover the dimensionality and addition of oids are mutually orthogonal concepts. Thus starting from classical ordinary data, one may migrate to higher forms of relational or object-relational data in any sequence, without having to recode application software. Our model does not deal with complex objects, which is left as a future extension

Current state and requirements in components and energy systems databases

With the objective to develop a suitable database for the Design4Energy (D4E) workspace, the requirement identification of the component and energy system database started from the analysis of the existing database solutions. The classification, evaluation and analysis of the state of the art of the BIM and energy efficiency oriented database have inspired the requirement identification and also the approach, concept and functionalities design in T3.2. This document then identifies the major related stakeholders of the envisioned platform and project outputs. Taking into account the project objectives and the interests of the analysed stakeholders, this report brings the requirement for simulation outputs which could help the end users or architects to understand the energetic performance of their on-going design, IT requirements in architecture, data structure and interface, as well as the operation and maintenance issues. As another main focus of this document, components and energy systems database (DB) are detailed described. It defines and recommends the parameters for different building components such as wall, roof, floor, windows and doors, lighting system, renewable energy system and HVAC components such as heat pump, boiler, energy storage and distribution. During the research of the database requirement, interviews, questionnaire, literature review, internal discussions with partners and energy experts, investigation of the simulation software and BIM technologies have been the main data sources. The key information presented within this document can be summarised as follows: · Objectives and vision of the component and energy system database. · Analysis of existing database solutions. By classifying the current practices into three categories: construction material database, component database and others such as building type database, different technologies and platforms are analysed. · Identification and analysis of the major stakeholders related to the D4E scope. · Questionnaire design and the collected results · Database requirement in system architecture, interoperability, data structure, user interface and user management. · Database requirement description of the simulation outputs, specifying the interesting data which could help the end users to understand their on-going building design. · Database requirement description of the operation and maintenance related issues. · Database requirement description of building components, including envelope (wall, covers/roof, floor), window and door. The recommended parameters are given in table format. · Database requirement description of energy systems, focusing on the subcategories like lighting system, renewable energy, heat pump, boiler, energy storage and distribution, in each subcategory, requirements for specific technologies are described. Introduction of the strengths and weaknesses of the latest and popular technologies is also included in appendices