One of the problems with frequent blogging – I’ve passed 1100 separate posts here – is that it’s easy to lose track of what I’ve discussed. I was sure I had already addressed today’s topic, but it turns out that I had only nibbled around the edges. So: What does code compliance mean and how is it related to safety? Or: what is safety and how is it related to codes?
The short answer is that code compliance – meeting the requirements of whatever building code is legally in force, and therefore meeting the requirements of whatever documents it references, such as various material codes – is a legal issue, while making a building safe is an engineering value judgement. The first is more or less explicit but doesn’t mean you have a safe building, while the second means that you believe you have a safe building but may not be able to prove it. We strive to achieve both, as do the vast majority of engineers I’ve ever met, but various conversations have convinced me that people inside the profession and out conflate the two.
Code compliance literally means that your design complies with the requirements of the code. If it’s a prescriptive code, such as the one that the AISC has for steel design, then it’s a matter of following the various requirements in design calculations and in detailing. I’m making it sound like paint-by-numbers and it’s not: there’s a fair amount of thinking required to fit the pieces of a specific building to the formulas in the code. If it’s a performance code, like some of the alternative methods of fire-protection, then the connection between design and code is less direct, but again the goal is meeting the requirements of the code document.
Safety is, in my opinion, not generally definable. It certainly isn’t code compliance, or every change in every code would mean that large numbers of buildings were no longer safe. It doesn’t mean something can’t fail, because anything can fail. It doesn’t mean our perception of safety, because that can easily be wrong. An old-fashioned and somewhat simplistic way of describing safety is a safety factor: divide the load capacity of a member by the load (actual or expected) and you have a number that you really hope is greater than one. There are two problems with this idea. First, the capacity comes from a code-based calculation of some kind and has its own fuzziness. Second, that simple idea works for individual members but is difficult to scale up to entire systems. The disaster of the space shuttle Challenger, for example, was in part enabled by people looking at the safety of individual elements but not the system as a whole. My personal take on safety is that it is an inherent property of a structure (or a machine like the Challenger) and what we are attempting to do with code-based analysis is get a handle on that property. The problem is that we only ever analyze models, not the actual thing, so our analysis and therefore our view of safety is never completely accurate. The building is as safe as it is, and our job is to figure out what that means.
Most of the time, this is fine. But what about when it’s unclear? A strict code-based analysis of a damaged building may say it’s unstable, but an empirical review of its performance may show that it has no visible damage even though it’s been damaged for years and has therefore weathered numerous storms. Or, conversely, a new building that has been designed and reviewed with respect to code can develop unforeseen problems.
We’re engineers, so of course we perform numerical analyses of the buildings we examine. But because we know those analyses to be, at best, blurry pictures of the actual state of safety, we also look at the conditions present in the buildings themselves. Reality overrides the model, which means when push comes to shove, safety overrides codes.
You must be logged in to post a comment.