*7.4.1 Selection of suitable traffic template*

Even for a building with just a single main terminal floor, the lunch time template is considered to be very intense since it presents the features of both start and end of day peak flows, but in the presence of concurrent interfloor traffic. However, the building which is the subject of this design is not simple since it has two entry/ exit levels. For the purposes of lift traffic analysis it is assumed that there is no resident population on the garage and lobby floors and furthermore, since the staff of the restaurant are not expected to travel during the busy lunch period, all three floors can be treated as if they are exits/entries of the building.

So, the specification by the template of traffic in terms of 'incoming' and 'outgoing' flows is convenient, as this example demonstrates, because the restaurant can be treated as a pseudo entry/exit floor. Consequently, for the building in question 'outgoing' traffic involves both up and down travelling passengers, and similarly for 'incoming' traffic.

During the lunch hour, the busiest period for the restaurant floor in this example, it is assumed that the "outgoing/incoming" traffic will be split 50% to/from the restaurant and 50% through the two real entry/exit floors where 10% passes through the garage and the remaining 40% via the lobby.

### *7.4.2 Populating the SEIS DemandProfile*

With the parameters of the traffic template established, it is now possible to calculate the arrival rates, for each 5-minute interval, of passengers at the populated floors heading for an exit floor (outgoing) and similarly the arrival rates at the entry floors heading for the populated floors (incoming), lastly between populated floors (interfloor). We also have the means of estimating the destination floor of each arriving passenger and so the number of passengers arriving at a floor and sharing a destination floor is derived according to the above percentages for each type of traffic flow.

The result is a three-dimensional matrix of per-interval arrival and destination rates that is most easily generated via the passenger data editor of a lift traffic simulator [47], which then will be responsible for generating individual passenger journeys, based on its own internal statistical formula. Several simulation runs should be generated to ensure a valid sample size. Subsequently, the passenger data matrix should be loaded into a spreadsheet for easier manipulation. The matrix is most concisely and consistently expressed as a SEIS DemandProfile, (see **Figure 5**), which provides a crucial mechanism for linking the building under design with the reality of its operation.

The data in the spreadsheet can then be exported as XML in the form a DemandProfile as a permanent record of the design and analysis that has been conducted. A key element of the DemandProfile is the ResponseQuality (red ellipse in **Figure 5**), which links demand rate to response, thereby capturing a measure of the quality of service during the sample period. The particular value of this link is illustrated in this example.

**Figure 5.** *Definition of a SEIS DemandProfile element.*

### *7.4.3 Using demand profiles throughout the lifecycle of the building*

During the building design phase the demand profile can be used to configure a lift traffic simulation, where the simulator will be responsible for generating individual passenger journeys, based on its own internal statistical formula, over each period of the demand profile. These simulations can then be used to assess the suitability of the proposed lift system – its handling capacity and its anticipated quality of service.

After the building is constructed and inhabited by the user population, data logging should be set up to record the real DemandProfiles as they occur, which should be compared with those of the design phase to ensure that a good match has been achieved. A match of design against recorded is more readily achieved for destination calls than for direction calls (where some interpretation of the data is required) but the demand profile is compatible with both (even a mix of) call types. Many demand profiles should be recorded to ensure a statistically valid set of results is used and the records should continue over the lifetime of the building to ensure that the characteristics of passenger demand have not changed and the ability of lifts to satisfy it has not deteriorated. If the match is not demonstrated the recorded results should be used to generate further simulations where the parameters of the lift system may be adjusted in the search for a more appropriate configuration. All demand profiles (planned and recorded) should be referenced and co-located in the Building Information Model (BIM level-3) [48] – once it has become standard practice to maintain such a resource for the management of a building and its assets throughout its operational lifecycle.
