In this project, i tried to come up with some ideas on integrating programming document and BIM models. it seems to be a very long process and i will continue to work on that as my PhD research.
Introduction
For centuries and years, a building was the result of a collaborative effort of a huge team of experts. As the body of human knowledge on buildings increased the members of that team increased as well. Now, all the collaboration between the members is becoming a big issue. For instance, even in a small project, structural engineer and the architect need to work closely back and forth to come up with a project that would behave architecturally and structurally perfect. During this process the architect needs to change his design tones of times and so does the structural engineer. When we add another team member (i.e. mechanical engineer) it would double the trouble. The architect needs to do tones of reviews during the design process to comply all the involving disciplines. It means time and money. So is there any way to prevent all these excessive reviews? BIM technology’s promise is to find an answer to this question.
What BIM does, is preparing a database, where each discipline can add information to that. So different disciplines would try to digitalize her body of knowledge and add it to the database.
So far there has been a significant progress on integrating different disciplines through the BIM database. But there are still more disciplines that should be added to the database and for the disciplines that are already connected, so many improvements are needed. One of the disciplines that should be added to the database is Architectural programming.
Programming
- What’s architectural programming
Programming is one of the most recognized disciplines both in architectural practice and architectural education. It is broadly accepted that programming, as a concept, is one of
The oldest in practice, but it has been recognized as an independent domain of study for only 60 years. William Pena is known as the father of programming, yet it doesn’t mean everybody would agree with him. Different scholars define programming in different ways, among them:
“Programming is a process. What kind? Webster spells it out specifically: ‘ A process
leading to the statement of an architectural problem and the requirements to be met in
offering a solution.’ ”(Peña & Parshall, 2001)
“A program is information the designer can use. It is an organized collection of the
specific information about the client’s requirements which the architects needs in order
to design a particular facility. This encompasses not only the expressed requirements of
the client, but all of the human, physical and external factors which will influence the
design. A program is communication. It transmits and interprets the needs of the client
to the designer.”(American Institute of Architects. & Palmer, 1981)
“Architectural programming is a research and decision making process that defines the
problem to be solved by design”(Cherry, 1999)
From all the definitions above, you can get an understanding of what is Architectural Programming. It’s a phase in design (sometimes referred as pre-design phase) where the programmer try to define the problem that is supposed to be solved through design phase. In order to do that, programmer will use different sources. These sources would range from the client picture of the future building to the urban codes. At the end programmer will collect and classify all the requirements that he has come up with in programming phase and classify them in a document. This document will be a hand out to the designer, and designer is supposed to comply the programming document. This document may also be used later to evaluate the design.
Phasing Architectural Programming
There are so many controversial issues involved in programming (e.g. the relationship between design and programming, data gathering techniques, etc) scholars have tried to address these issues and they have phased programming for different purposes and so in different ways. Purpose of this paper is to form a platform to categorize different pieces of information in programming document to be used as a digital database and cooperate with the other digital design tools. here, based on that, we can distinguish these three phases in all of them:(Sanoff, 1992)
1- Collecting data,
2- Analyzing and processing data to requirements,
3- Presenting requirements to the designer
4- Evaluating the design
1- Collecting data
This is the first part of each programming project. Different scholars have suggested different sources to collect the required data. Basically programmers can use six sources to collect required data for programming:
1- Client/User
2- Project site
3- Existing literature (more description, what parts are easily available, what should be considered as future projects)
4- Codes and standards
5- Precedents (previous Programming Documents and built projects)
6- Experts on building related fields
The result of data gathering phase would be raw data and information on different topics related to design, so far, programmers has proposed different platforms of organizing the accumulated data from this part and they have used different criteria. Our criteria to organize the data would be “How we can transfer this data to a digital database?” based on this criteria:
1- Objectively measurable data:
- Numeric parameters:
Such as number of users, number of a certain space. These kind of data comprise of a parameter and a number like: Number of users: 15
Sometimes it would be a range that a parameter should fit into, for example: number of visitors per day: 12-20 people (number with precision) (more clear examples)
- Parameters with limited choices:
Sometimes we have limited choices for a parameter, for example the answer of this question: “what are the choices on mechanical equipments for the project?”
- Adjacency , or “What are the adjacent spaces to space A”
We can also categorize explicit requirements as quantitative data, such as “we want to use dark blue carpet for the auditorium”
- Number of users
- Allocated budget
- Time limitation to complete the project
- On what schedule the project may receive the allocated budget
- What’s the expected area for each space
- …
-
2- Subjectively measurable data: this type of data cannot be directly or indirectly definable. These are basically subjective goals and missions by client and/or descriptive statements by user/client on the future building. “I need a cozy room” or “I want my building to reflect African American culture” is not definable through mathematical ways, still we can find some ways that may assure that designer has considered them all through design. For example by reminding her at the right time, when she is working on a specific part of the design. We can also make sure that client/user has all the ideas in her mind expressed. It’s possible by having a concise database of precedents where client/user can refer his statements to them. So we can create different ways and methods to assure that client has expressed all her ideas.
Each datum or piece of information that we receive in data gathering phase, can be expressed by a parameter, the assigned property (quality or quantity), and the party who has asked for this property, for example, when client says “I want the backyard to be relatively a private zone”, it would be translated to:
Backyard: Relatively private zone, Client (ontology) (backyard: object, parameter: private, value: relative)
In this example “Back yard” is the Object, and “private zone” is the parameter and value is relative
Later we may assign more properties to this parameter, for example:
Back Yard: 100-150 square feet, urban codes
There would be different properties assigned to a parameter, for example for “Space A” we can have parameters such as:
Assigned Area, adjacent spaces, number of users, lighting specifications, view preferences, user preferences, …
The Ideal result of data gathering phase would be table like this:
| Object | object family | Property 1 | Property 1 type | Property 2 | Property 2 type | Property 3 type | Property 3 type | Property 4 type | Property 4 type |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
Based on the parameter type the required properties would be added to the table automatically, the programmer then should start to fill table cells by going though different resources. He may not be able to fill all the cells though.
But if form separated tables based on their properties for each family, or each category. It’s easier to organize all the information. In that case the result of programming phase can be several tables in a database that are interconnected together by several queries.
Data analysis:
Codes and standards can be embodied into a database, by using them, we can automatically generate new cells in the table and fill some of the filled cells. We can also control the filled cells to make sure if they meet the standards or not
For example, if we already know that we have an auditorium for 200 people in our program, by using embodied standards and codes, we can generate these information:
1- How many square feet we need in that space
2- How many fire egress we should have
3- How many square feet we need in back stage
4- …
After analyzing data, the programmer may encounter some inconsistencies. For example there would be a contradiction between user preferences and fire egress codes. Then they should try to come into a compromise and make a decision.
Presenting a programming document,
By this time, the programming document is ready, now we should present it to the designer So far, people have used different criteria to propose a format in presenting programming document, what they have in common, is they all have been based on an analog design process. So programmers assumed a process that designer would go through to design a building and they would try to classify all the requirements that designer should meet based on that process. The main difference in this research is, we are not establishing the format completely based on a pre-assumed design process, but through the BIM design tools we can monitor the designer. So we don’t need to assume a process that designer would go through, instead, we monitor him, and we will give him the information that he needs.
These are the monitoring options that we have in a BIM design tool:
Indirectly (implicit)
- Menu or tool (that designer has chosen)
- Scale of screen
- Previous actions
- Areas of model that curser is touching
- The area of Model that designer has clicked
Directly (explicit)
- We can create an interface where designer can tell us what he is doing.
By combining these two methods we can provide designer by the pieces of information that he needs. The interface would be a side window in a BIM design tool that shows the appropriate written information and precedents
Evaluation
As we said at the beginning, there are directly measurable and indirectly measurable pieces of information in the programming document. For the first category, we can evaluate all of them by comparing the design in each stage to the programming document.
For the subjective requirements we can send them to client and/or programmer and ask them to approve or not.
The benefit of such a database is not just more time and money efficient process, but also, the designer can track back all the requirements that are set and see how the programmer has come to this decision, it actually will makes it clear how critical those requirements are and also designer would have a better understanding of them, it would make the negotiation between them easier.
An example:
In this example, I tried to create some sample tables for the programming database I used Autodesk Revit Architecture, DB link, Ms Access database as a base to form my tables. This tool exports a Revit Model to a Ms Access database. Obviously that database doesn’t include all the information of a Revit model. But it’s an open source database and later it’s possible to extract more information from a Revit Model into that Database and present them through some tables.
I added some tables to that table that would represent part of a programming document, here you can see one of them:
In this example, we chose same pattern for data organization as it is used in Revit, we divided all the pieces of information into categories, families and types At first three columns, the programmer should determine which category, family and type of information he wants to enter into database.
This table basically covers data about the area of the rooms. This data is a range between two numbers that are assigned by programmer (column 6 and 7) the next column, is the retrieved real space area from the Revit model, by using some queries, we can easily retrieve that information from the RDB link Ms Access File. By comparing these numbers together, we can determine whether designer has met the requirements or not!(evaluation)
As said above, this is just an axample to show that this strategy would actually work in this context. The main job would be to categorize are the potential data from programming document into these tables so that the entire programming document is covered.
