The first design project that Engineering Science students were tasked with in 2016 was to pick a pedestrian bridge of a certain minimum size and redesign it as a truss bridge. This gave us practice applying our design work to the real world, even though our bridge designs will never actually go forward.
My group selected the bridge over Queen St. West that connects Nathan Phillips Square and the Sheraton Hotel. What we can only assume was once a door into the hotel has since been replaced with a window, making this bridge totally useless. Because of this, there was no risk in redesigning it, but it’s quite likely that there was no reward either. A redesigned bridge to nowhere is still a useless bridge.
As the first design project of my engineering education, there are a few parts of my Engineering Design Process that started to emerge, and were either modified or cemented in later work.
Our design work started with an assessment of the bridge. If this were to be related to my Engineering Design Process (see above), it would fall under the category of background research, as well as understanding the context and the past solution attempt in that specific context. Unfortunately, because the bridge was apparently purposeless, with a traffic flow of zero, my team and I were left only to hypothesize that at one point the bridge had served the function of providing hotel patrons with privileged access to Nathan Phillips Square. We were further constrained by the assignment, which was to design a bridge that makes Toronto more beautiful (the reason given for this requirement was that the Blue Jays’ recent consistent success was bringing more tourists to the city).
Our work centered around picking a truss type. We decided early on that for aesthetic and structural reasons, we wanted our bridge to be arched, but our initial attempts to solve an arched Pennsylvania style truss only proved that our technical abilities and time were limited.
Eventually we simplified to an arched Pratt bridge, which is much simpler than a Pennsylvania to solve. For our team as novice designers, truss types can be considered features of the bridge, since we are simply choosing from a list of trusses that others have developed. Similarly, whether or not to have an arched bridge is also a feature decision.
By way of standards, the only rule we were working with is that the truss had to be statically determinate. This significantly reduced the number of trusses that we could attempt to model our bridge after, but still gave us room to modify features and tweak the design as we saw fit.
There was no requirement to build our bridge, so testing involved calculating the stresses on the bridge. It was only really at this point that we recognized a key metric: the stress on all the members. Our criteria was to minimize the maximum stress felt by any member of the truss, but we weren’t working with any hard constraints. It turned out that our decision to arch the truss worked in our favour at this stage, because it spread the stress out evenly over the top and bottom members.
Our prototyping in the final stages of design took two forms. The first was developing a mathematical model, which we did through a truss solving computer program and pen and paper. The second was a visual representation, which I made on SketchUp. I hadn’t used SketchUp for a couple years before this project, so I relearned it and learned some new features; I categorize these activities as “Representation Research” in my Design Process. Finally, our team combined all of our representations into a trifold poster, which we presented to our class and assessors.
Unfortunately, we failed to keep adequate records of our decision process, but in many ways that process was not worth recording anyway because of its poor quality. Regardless, from my description you can see the beginnings of the process that I have outlined as my own.
Theodore Block 