Elevator | EPFL Graph Search

An elevator or lift is a machine that vertically transports people or freight between levels. They are typically powered by electric motors that drive traction cables and counterweight systems such as a hoist, although some pump hydraulic fluid to raise a cylindrical piston like a jack. In agriculture and manufacturing, an elevator is any type of conveyor device used to lift materials in a continuous stream into bins or silos. Several types exist, such as the chain and bucket elevator, grain auger screw conveyor using the principle of Archimedes' screw, or the chain and paddles or forks of hay elevators. Languages other than English, such as Japanese, may refer to elevators by loanwords based on either elevator or lift. Due to wheelchair access laws, elevators are often a legal requirement in new multistory buildings, especially where wheelchair ramps are not possible. High-speed elevators are elevators that move faster than regular elevators and are common in skyscrapers and tower

Specifying reactive system behavior

Shane Sendall

Fundamentally, the development of software applications involves dealing with two distinct domains: the real world and software domains; the two converge at the point where a software application is used to make an unsatisfactory real world situation into a satisfactory one. Thus, software application development is a problem solving activity that assumes a problem has been identified and a software application is desired to address this problem. In this context, it is necessary to take measures that ensure the solution will be both adequate and appropriate with respect to the problem. In particular, it is of utmost importance that the problem in hand and the application's role in helping to solve it are satisfactorily understood by the development team. If this condition is not observed then the application produced is doomed to be inadequate and/or inappropriate, independently of the capabilities of the available technologies and resources, and also independently of other wicked aspects of software development: constantly changing requirements, time-to-market pressures, significant social, political, ethical or economic issues in the project, etc. The principal objective of this thesis was to improve the state-of-the-art of specifications that are used to communicate to the development team the behavior of the (future) system. In addressing this objective, this work initially involved defining the essential requirements of specifications that could ensure that the development team has a precise, correct and common understanding of the way the system is required to behave. As a result of analyzing the identified requirements, two general kinds of specifications were distinguished and perceived to be necessary to address the requirements adequately; one that addresses the concerns of the designers, providing a precise description of the system responsibilities; and one that addresses the concerns of the stakeholders in general, providing an informal description of the goals that the stakeholders have against the system. The first specification is referred to as the Behavioral Design Contract and the second one is referred to as the Behavioral Stakeholders Contract. In this thesis, these two specifications were concretely realized as part of the ANZAC approach. The ANZAC approach defines two work artifacts called the ANZAC use case descriptions and the ANZAC specification, which express the Behavioral Stakeholders Contract and the Behavioral Design Contract, respectively. ANZAC use case descriptions offer an informal and usage-oriented description of the concordant goals that the stakeholders have against the system. An ANZAC specification offers a precise, operational description of the system's responsibilities in servicing all possible requests that it can receive over its lifetime; it uses a restricted subset of the Unified Modeling Language (UML) and its Object Constraint Language (OCL). In the ANZAC approach, the ANZAC use case descriptions are developed following the ANZAC use case framework. This framework defines the context, purpose, style and form of an ANZAC use case description, and it provides a goal-based approach to use case elicitation. Once a number of ANZAC use case descriptions are established, they can be refined to an ANZAC specification. This refinement procedure is (informally) defined by the ANZAC mapping technique. An ANZAC specification is developed by the description of three models, which each express a different but complementary view of the system. These three models are called the Concept Model, the Operation Model, and the Protocol Model. The Concept Model defines an abstract system state space in terms of concepts from the problem domain, the Operation Model describes the effect of system operations on the system state, and the Protocol Model defines the correct behavior of the system in terms of its (allowable) input protocol. As a "proof of concept", this thesis demonstrates the ANZAC approach applied to an elevator control system, which is used to show how ANZAC offers a clean approach for capturing the Behavioral Stakeholders and Design Contract. The elevator case study demonstrates the mapping between the Behavioral Stakeholders Contract and the Behavioral Design Contract using the ANZAC mapping technique. It also highlights the difference in the level of precision and formality that can be found between ANZAC use case descriptions and an ANZAC specification. Furthermore, it demonstrates some of the more advanced features of the ANZAC approach, in particular, its ability to specify performance constraints and concurrent behavior.

EPFL2002

Virtual Elevators' Contribution to Sustainable Transport Policies: The Importance of a Smart Regulator and "Not-Too-Smart" Cards

Tristan Chevroulet

The most significant contributions of new technologies to the implementation of sustainable urban travel policies appear to be twofold: a better understanding of users’ behavior, and the improvement of interfaces between operators. Smart cards, i.e. chip cards which communicate with the database of a billing company, have the potential to combine the qualities of both of these contributions. But they also raise new problems. In Japan, a financial transactions company is developing a new payment system which coordinates superstore chains and public transport supply. Just as elevators will enable people to move freely within buildings, this system will enable customers to reach the superstores for free from the outside world. Analysis confirms that this new concept has the potential to stimulate public transport demand. However, three issues need further consideration. First, private businesses may access transportation, financial, and even property data of travelers, which may threaten their privacy. This paper proposes a concept that would prevent such a system failure. Second, small businesses could be discriminated against on the grounds that the turnover they produce does not suffice to bear the cost of running virtual elevators. The study highlights the conditions in which local authorities may require leading businesses to cooperate with smaller ones. Eventually, since virtual elevators may rely upon state transport subsidies while following private commercial profit objectives, the paper also stresses in what matters states and local authorities should require commitments from private partners. The conclusion underscores the importance of public authorities’ involvement from the earliest steps of development of the system until and during operation. More specifically, it contrasts two distinct policy requirements: subtlety as the regulator’s main quality and “not-too-smart-ness” as a major characteristic of electronic cards.

2006

Quasi-static cyclic tests of two U-shaped reinforced concrete walls

Katrin Beyer, Alessandro Dazio

U-shaped or channel-shaped walls are frequently used as lateral strength providing members in reinforced concrete (RC) buildings since their form does not only provide strength and stiffness in any horizontal direction but is also well suited to accommodate elevator shafts or staircases. Despite this popularity, experimental results on the seismic behavior of U-shaped walls are scarce. For this reason a research program with the objective to provide additional experimental evidence for such walls under seismic loading was developed. It included quasi-static cyclic testing of two U-shaped walls at the structural engineering laboratories of the ETH Zurich. The walls were built at half-scale and designed for high ductility. The main difference between the two walls was their wall thickness. The project was chiefly focusing on the bending behavior in different directions and therefore the walls were subjected to a bi-directional loading regime. This article discusses the design of the test units, the test setup and the test predictions. Finally the main results are summarized in terms of failure mechanisms and force-displacement hystereses.