Course Reflection

My expectations  for this course were to learn about the concepts behind BIM and some of the emerging technologies in the industry. Furthermore, I was hoping to gain a better understanding of how buildings are monitored over their useful life. I certainly feel that all of my expectations were met at some point in the short ten weeks we had to discuss intelligent buildings. In fact, in many ways, my expectations were exceeded in this course if only by the quality of discussion and personal interest in the subject matter. As David Morrison reflects, the topic of “Intelligent Buildings” is an exciting one, especially for architectural engineers such as myself.

What felt like the course introduction, in the first two weeks, served to whet my appetite for the lectures to follow. I found the lectures given by representatives of Revit and Bentley to be particularly interesting, and useful as an overview of what these two modeling programs are about. Learning that databases are responsible for the operation of these programs made me more willing to investigate database design as we were assigned. Not only was I willing to learn, I found our discussion of databases to be extremely intuitive and edifying, especially having no previous knowledge about databases. I agree with John Scanlon that the overall format of this course is clear and informative, even for the most basic level of understanding. I further agree with Elda Cifligu that I got out of this course what I put in.

That being said, my only difference of opinion with the format of this course is the relative time spent on databases. I felt that the initial introduction to databases and the following tutorial, in conjunction with the excellent online tutorials, was more than sufficient to develop a basic understanding of databases. I would have preferred to see the second week dedicated to databases spent on further development of our term projects, or some other aspect of intelligent building (sensor use comes to mind). Other than this, I felt the work assigned was fair in its magnitude and its timing. I appreciated the checkpoints on our term project and the fact that it was due a week before the madness of Week 10 set in.

In general, the tenor of this course turned out to be far more interesting than I expected. By maintaining an overview of the topics we explored, and just enough technical detail to get our feet wet, I felt the course remained fresh and exciting for the majority of the time. I’ve always enjoyed the format of the courses conducted by Professor Mitchell, but I found the content of this one to be particularly interesting and useful. It would have been futile to attempt to teach an in depth course on all the topics covered in this class, and there are plenty of technical courses worked into my schedule already. This course was a refreshing break from the technicality of my other courses, and an eye-opening introduction to larger (arguably more important) concepts that I will be facing in my future as an engineer. In short, I felt the level of detail in this course was perfect, and the content useful for focusing my attention on relevant issues in the engineering world today.

Temperature Sensors

While initially, sensing temperature may seem like a simple concept (and it's been getting done for a very long time now) the actual details of what we are sensing can become quite confusing. In its most basic sense, temperature is a measure of the movement of molecules within a body of matter. That matter can be solid liquid or gas, and more frequent movements translate to higher temperatures (with absolute zero at the bottom of the scale, meaning no particle movement at all) The reasons we care about temperature are varied, but mainly we want to be comfortable or we want to ensure that a certain process is happening by manipulating the temperature. Of course our perception of comfort is based on our own sensing of temperature by biological processes far more complex than the processes we use to quantify temperature.

Obviously the thermometer is the simplest way to sense and understand temperature. We figured out pretty early on that certain fluids expand when they are heated, so that their volume is a function of temperature. By controlling and marking this expansion of volume we were able to quantify temperature. As John points out, we were later able to recognize the same principle applies to solids, and we began to use this to control the movment of thin metal strips, which would in turn control some basic circuitry, mainly for switching on and off some electrical process. Of course, this is the principle by which most early thermostats operated.

As we progressed in knowledge of electrical properties of materials, it was found that the resistance of certain conductive materials decreases as we increase the temperature, and so we developed thermistors made of ceramics or polymers to effectively convert a change in temperature to a change in resistance that could be easily measured. We also knew that the current changes between to metals at different temperatures, so a slightly more complicated Thermocouple circuit was developed, where this change in current can be measured across dissimilar metals. Furthermore we found that different metals behaved more predictably for certain temperature ranges, so a number of sets of metals were used for varying applications. Finally, the resistance in a coiled wire was found to be more accurately measurable, so RTD's (made of a homogeneous wire wrapped around a ceramic core) became prominent. These could be configured differently to accomodate different temperature ranges and provided high accuracy and repeatability.

Mike does a great job of explaining the usefulness of all of the sensors mentioned above. However, there are still some applications in which even RTD's and Thermocouples cannot be used. For example measuring the surface temperature of an object that is moving or one that cannot be disturbed becomes quite difficult with the sensors mentioned above. Rather than measuring a change in a specific material's response to a temperature, Pyrometers are able to measure a temperature directly as a function of an object's electromagnetic radiation. The methods by which this is acheived can become rather complex, but in their simplest form all pyrometers consist of a lense to concentrate radiation into a point or array of points and an absorber, which chemically translates radiation into terms of flux. It is at this point that the line between sensing and transducing becomes blurred for me. David gives a good explanation of these principles as applied to an array of infrared sensors (thermography).  By some means of transduction the radiation is translated to thermal energy and the thermal energy is translated to an electrical current. The figure below helps explain the process.

References:
http://drexel.summon.serialssolutions.com/search?s.q=thermal+radiation+sensor

http://site.ebrary.com/lib/drexel//docDetail.action?docID=10438390

http://www.electronics-tutorials.ws/io/io_3.html

http://en.wikipedia.org/wiki/Pyrometer

es queue el

Nathan gives a pretty good overview of the function of SQL servers, and the degree of standardization that is common to the language. As he mentions, it is important to have a Structured Query Language to manage databases in an understandable way, allowing us to find and modify data once the database has been created. After some initial confusion pertaining to the jargon used to describe how SQL works, I found the actual functions it implements to be very intuitive. Each function's name describes what it does. For example, the all-important SELECT function allows programs to search and retrieve data from a specific database table, with further modifiers embedded within the function to refine the search (FROM, WHERE, etc.), and organize the output (ORDER BY, GROUP BY). I found Wikipedia's explanation of this function (and others) very helpful.

Figure 1 - SELECT function explanation

I like that David describes the databases themselves as "glorified excel sheets," especially since this definition is coming from someone with some experience with databases. From my rudimentary understanding of the topic, that is exactly how I pictured and SQL database, some enormous table made up of labeled columns with rows of data beneath. It makes sense that by this system, and particular piece of data can be pinpointed by some row and column designation, much like an X and Y coordinate in the cartesian system.

What intrigued me most about this week's topic was not necessarily how the system works, but how often it needs to work. I gather from the articles I read, that every single user-interfaced program uses some form of database and query system to make it run. For simplified applications this may be a flat-file-database, as David explains. However it is my impression that, for the large majority of complex applications, the SQL format is used. A recent article puts into perspective the importance of the ability to manipulate and query these formatted data.  As our sensing capability and aptitude for data recording grows, the challenges involved in organizing, maintaining, and using this data also grows. For example in the medical field there are virtual reams of unused data pertaining to patient records, and no unified system for managing all of this. As data becomes more and more digitized, it seems reasonable that we must decide how we want to organize this data so that it is easily accessible when we need it. The SQL is currently the ANSI specified way to do that, and while it is not without complications, the basic structure of database and query language remains the same across the board.

Finally, one of the biggest issues in current SQL design is the timing of the SQL servers. Database size has grown significantly since the SQL language was invented, and as a result we are having to deal with time lag as SQL applications search through these seas of information for specific data. ANSI is still updating specifications, with its latest release in 2012, to account for the evolving nature of database organization and navigation.

References:

"Database Management: Big Data will soon be the norm" - Sunday Business Post

SQL For Dummies - 7th Edition

Term Project - Green vs. Intelligent

I am working with Issa Haddad and Jay Ng on this project. We are looking at green vs. intelligent building in light of our senior project, with our design goals serving generally as the “green” aspect and an attempted BIM model as the main “intelligent” aspect. For more background information on our senior design project see either Jay or Issa’s post.

As Gayaneh mentions, the definition of intelligent building seems to be muddy at best. While “green” construction is better defined, especially with the advent of LEED certification in the early 00’s, the concept tends to be mingled with that of intelligent building to form one very confusing impression of the “architecture of the future.” Furthermore this impression tends to resemble a conglomerate of all the cool ideas and new technology we’ve been exposed to, invoking visions of glistening facades and space-agy designs, self-driving cars parking under wind-turbines as a spandex-clad future-human emerges with the press of a button, suavely removes his google-glasses and jetpacks up to the green -roof of his sustainable habitat (by 2020 they will no longer be called homes.) You get the picture.

Our aim, first of all, will be to clear away all of the misinformation and confusion associated with the concepts of “green building” and “intelligent building” by presenting a singular, clearly stated definition of these terms. As Jay points out, the “green” aspect at this point seems to be most easily definable by LEED goals and requirements. “Intelligent building” may likely end up meaning something very similar to what Professor Mitchell has proposed in his first lecture. With a clearer picture of what these separate parts are, we hope to gain a clearer picture of what our senior design project is, or wants to be.

The next step will be an investigation of BIM vs. traditional approaches to building modeling. Steering clear of the obvious advantages in ease of drawing collaboration, modeling capabilities, etc, we hope to take a deeper look at the comfort level of the people using BIM. Is it appropriate in all circumstances? Is it always better? My guess is that the majority of the time BIM trumps all, but there may be a few specific cases we run across in looking at the applicability of BIM to such green analyses as daylighting, stormwater, energy, and life cycle. I suspect interoperability between programs designed for these specific analysis will be flawed if not completely unworkable.

Of course all of this will become clear as we attempt to model our green resource center and include as many systems as Revit will allow. We are hoping that through a discovery of the various capabilities of Revit and linkable analysis programs we will be able to get a much better handle on what exactly our building requires and how our proposed systems can affect these requirements. With net-zero energy, runoff, and environmental impact as our design goals, It seems that Revit will become an indispensable part of figuring this all out.

Some quick research on the topic of Green BIM yielded an interesting viewpoint on the applicability of BIM in the future of green building. It seems that BIM is on the rise in the field, and small “green” renovations are taking precedence among the majority of engineering and contracting firms. The report I looked at went into some case studies, each showing the importance of BIM for integration and import to other analysis programs, allowing for more focus on the design of the building rather than crunching numbers and entering data. This in turn led to higher efficiency in material, time, and money. One of the most interesting examples, pictured below, was the Grange Insurance Audobon Center in Columbus OH,  which used a number of BIM programs for daylighting analysis that clearly influenced the shape of the building.

References:
Green BIM: How Building Information Modeling is Contributing to Green Design and Construction. McGraw Hill, 2010

Not viewable online, but available for download here.

The Future of BIM Interoperability

I agree with Nathan that BIM will be integrated into the construction process regardless of problems with information transfer. While interoperability is admittedly a difficult and unavoidable problem in the current push for BIM as the industry standard for transfer of design information, I see some hope for improvement in the near future.

Within the next 5 years, it is my opinion that interoperability among programs within a specific software provider's repertoire (for instance, all Autodesk products) will improve to the point of near fluidity, so that there is even transfer to a central database of all aspects in a model. (This is one example of such a case in recent history) As Mr. Kuszewski discussed "saving to central" and "cloud-based computing" last week, it became evident that this level of capability is certainly present and need only be implemented across all products in a process known to the scholarly community as "data alignment." In essence, it is merely a process of organization and intentional consistency within a software group to facilitate interoperability and eliminate data loss between products/software-types.

However, in the same time period, I would not be surprised if the chasm of interoperability between competing software groups (ie. Autodesk vs. Bentley) widened. From the previous week's research, it seems like the degree of difficulty in information transfer is directly linked to the depth of information contained in a model. For instance, 2-D CAD models can very simply be converted to an open format, while 4 and even 5 dimensional models in Revit may contain a large amount of information about the individual building members that cannot be transferred cleanly to any other format than that in which they were created. By this line of reasoning, increasing capabilities of competing software types may likely complicate the transfer of data between them.

The solution to this un-interoperability, as Elda describes so well, might just be push for the IFC file format as a required standard. Despite many designer's aversion to this file type, it seems that on a global level, the IFC format is encouraged because it is an open source file type. The capabilities of design using this format are not as limited as one would think, and it certainly appears that they are improving. The Build Qatar event in 2012 was a great showcase of these capabilities.

Sources:

Aligning Misaligned Systemic Innovations: Probing Inter-Firm Effects Development in Project Networks

Intelligent distributed production control    

Asite announce BIM Academy, BIM Unlimited, Aidea and Niven Architects as winners of Build Qatar Live 2012

Interoperability - Why can't we all just get along?

I agree with John, that the current state of interoperability is insufficient given our level of technology.  Often the approach to transfer drawings to/from CAD is so difficult that it is easier to start from scratch. Last week as I listened to Group E discuss the capabilities of computer software and hardware, I was intrigued by the idea that all of the different programs for building modeling should have some sort of intercommunication. This fact seems obvious from an outside perspective. However it is easy to see how each type of modeling developed separately, catering to the specific needs of its respective industry. Of course, HVAC contractors are going to have different drawings from that of a structural fabricator/erector, and so on. 

I saw this first-hand when working with a steel subcontractor on my last co-op.  The architectural drawings were different from the structural drawings, which varied even from the outside erector's steel drawings, which further varied from our own stair drawings, and all of this had to fit inside the openings on the inconveniently separate precast plank drawings. There was an enormous amount of coordination required just to fit a stair tower into a building for which drawings had existed almost a year prior. All of this confusion could clearly have been reduced by the implementation of one unified building model. (To the contractors credit, they did provide CAD drawings after a while that could be used by all of the utilities contractors.) The availability of a singular 3-D model, at the very least in terms of building geometry, is an invaluable asset over the course of project.

As an idealist, I find it frustrating that, as Nathan and David point out, perfect interoperability will likely never exist due to the nature of competing industries and numerous technical issues such as incompatible XML schemas and display outputs. I would further point out that the diagram Elda used, while informative in showing the relationship between each program, is somewhat misleading in showing two-directional arrows between every linked program. Although I'm not completely sure, I would suspect that some, if not most, of the programs listed are not compatible in both directions. For instance, something developed in SAP 2000 cannot be converted to a general Tekla Structures format, then reconverted to Bentley, and then converted again to a format viewable in Autodesk programs. Still, it seems that the way forward for most compatibility programs seems to be native BIM formats such as DWG, RVT, DGN, or GSM files, as shown in Figure 3-5.

All this considered, I wonder if it would be beneficial for a third (or 25th or whatever it is) party to develop a program that merges the top BIM file types into some sort of super-program that handles the functions of every BIM program available and compiles them into one cohesive model. Such a program, if it were successful, would of course greatly enhance the construction process. However, given the much more likely possibility that it flops, the effort would only serve to muddy the already murky waters of BIM compatibility.

Sources: 

BIM handbook: a guide to building information modeling for owners, managers, designers, engineers, and contractors

Chapter 3 - Interoperability

 

I agree with Nathan that the future implications of sensor capabilities can be terrifying. Beyond domestic or commercial use such as in cars or building control systems, there is a lot of money being poured into military sensor technology. Increasing sensor capabilities have moved from equipping soldiers with night-vision, rangefinders, and the like, to equipping UAV’s (Unmanned Arial Vehicles) with these things. In my opinion, the ability to identify and fire on targets without having to physically participate or maintain a line of sight is one of the most frightening implications of sensor technology we are facing in the near future. Clearly, the ongoing conflict between US and a number of different threats in the Middle East has created a demand for the use of sensor technologies such as infrared imaging for identifying enemies unbound by the traditional rules of combat. It can be argued, and recently released information suggests, that without sensors to supplement their vision, soldiers may not have been able to “catch” Osama Bin Laden, and likely a number of other terrorist targets.  The benefits and power associated with possession of the newest and most accurate sensors can be seen in this example, but now the conflict is purportedly ending, and we are still advancing our technology.

One of the latest efforts has been to equip UAV’s with increased capability for defining a target. Much like the self-driving cars that John wrote about, these UAV’s possess highly sensitive cameras, wind instrumentation, and even radar, all backed by algorithms that help the aircraft interpret all this data into fluid movement. One of the most exciting emerging concepts in UAV technology is that of a swarm UAV. As sensors have been getting smaller and smaller, so have the UAVs carrying these sensors. Now Miniature UAV’s or MAV’s are widely used by armies in a number of countries. Only 2-3 feet long, these MAV’s can be transported and assembled by a regular foot soldier and used for reconnaissance without any fear of personal injury. The concept of swarm UAV’s is much what it sounds like. A swarm of UAV’s can be deployed around a base vessel such as a submarine or destroyer, which is covered in an array of sensors. Data from the UAV’s can then be transferred to the vessel, and the UAV’s used to jam any third-party radar, essentially making the vessel invisible and acutely aware of its surroundings. Furthermore, the production-line mentality of UAV’s make them highly replaceable so that there is virtually no risk in sending out one or a swarm of them to identify (and sometimes destroy) a target. The implication is a sort of distant, unmanned warfare that I would fear to see in action.

Sources:

http://en.wikipedia.org/wiki/Miniature_UAVs

http://link.springer.com/content/pdf/10.1007%2Fs10846-012-9698-1

http://search.proquest.com/docview/216203750

Mitch Butler Intro

I am an Architectural Engineering major who transferred to Drexel from Burlington County College in 2010. My original goal was to become an architect, but after realizing architects don’t build buildings, I decided on architectural engineering. Throughout my time at Drexel, I’ve been seeking to find ways of integrating aesthetics into the functionality of a building, and have often found that good form follows succinct structural design. That is to say, architects should listen to the structural engineers.

In this course, I expect to learn more about the concepts behind BIM as well as some of the technologies emerging in the industry. Particularly, I hope to gain a better understanding of how buildings are monitored over their life, and how this modeling system can be used to predict and mitigate problems. I’m expecting that better and better models will be able to track long-term structural behavior such as creep and foundation settlement.

I would define “Intelligent Buildings” as those buildings that make use of current technology and knowledge in various disciplines of engineering to increase the efficiency of their construction, operation, and maintenance. I believe that all systems, including Structural, Electrical, HVAC, Building Envelope, and even Architectural can benefit from an informed approach to design and tracking of a building.

Architectural Engineering & BS/MS Students

Here is the list of Architectural Engineering students in the course.  This post is also used to create a "label" for each student so it's easy to label your posts later. – Updated 1/14/2013

Group	Last Name	First Name	Major
B	Barry	Nathan	Architectural Engineering
B	Ben-David	Tom	Architectural Engineering
B	Butler	Mitchell	Architectural Engineering
B	Cifligu	Elda	Architectural Engineering
B	Morrison	David	Architectural Engineering
B	Sawin	Michael	Architectural Engineering
B	Scanlon	John	Civil Engineering
C	Bregande	David	Architectural Engineering
C	Hindes	Brian	Architectural Engineering
C	Houde	Kayleigh	Architectural Engineering
C	James	Daniel	Architectural Engineering
C	Lancellotti	Jeanine	Architectural Engineering
C	Martines	Natasha	Architectural Engineering
D	Gonzalez	Maria	Architectural Engineering
D	Ng	Junwah	Architectural Engineering
D	Patel	Jalpesh	Architectural Engineering
D	Pauliushchyk	Margarita	Architectural Engineering
D	Tedesco	Matthew	Architectural Engineering