Automating the inconvenient

The challenge

Will the automation of our repetitive work let us do away with paper drawings and give us more time to think?

In this article

  • How we automated the layout of emergency lighting.
  • The immediate impact that automating code-drive tasks is having on our business.
  • Our thoughts on how we can best roll automation out across a number of our processes to close the gap between design and documentation.

“People argued forty years ago that the calculator might put the engineer out of work,” says  Justin Szabo, an electrical engineer in Arup’s Building Services team. “What actually happens with these tools is they free someone up from tasks they probably didn’t want to be doing to begin with."

Justin is trying to shave a three hour job down to 15 minutes—in this case, the repetitive task of laying out emergency lighting. Using Dynamo, Justin wrote a script to automate the task. He is now working with a team to refine the script into a product that’s scalable across Arup. This means the program needs to not only be robust enough to handle a variety of layouts, but user-friendly enough to be taken up by engineers without a background in computer modelling.

Translating Technology

Laying out emergency lighting is a completely code driven process. Different lights have different outputs. Those outputs govern the requirement for how close together the lights need to be. On your typical project, it could take three or more hours to produce a layout by hand and check for compliancy. Justin Szabo is leveraging technology to reduce this to the push of a button.

While tools like Justin’s will reduce the amount of hours our service engineers are required to spend on certain jobs, it certainly won’t remove them from the process entirely. A level of technical expertise is still needed to pilot the software. As our Arup colleague, Dan Hill, says: the engineer is the shepherd and the script is the sheepdog, working under the engineers’ guidance. 

By simplifying and speeding up the repetitive aspects of these job, our engineers will have more time to communicate with design and construction teams, and create platforms for new applications.

“I see this as the first of many projects that will remove the gap between design and documentation. Where you can design and then produce a drawing or 3D model that can be built off right away.”

Prototyping, Testing, Iterating, Collaborating

Justin Szabo is one of a number of engineers working across Arup to speed up repetitive design tasks like checking calculations, formatting and data manipulation.

Every design and every designer is different. We have hundreds of automation processes on the go, using anything from Grasshopper, to Revit, to Python with teams in Sydney, Melbourne, Brisbane and Singapore developing parametric scripts to automatically update and optimise designs on options. The real challenge is balancing standardisation with the unique requirements of each project.

Justin is currently working with a research team to scale his Revit script into a usable product. This involves talking with other service engineers to make sure the software will be a simple, transparent, ‘plug and play’ model. 

Engineers are often (and understandably) reluctant to use ‘black box’ tools developed by other people for other applications where they can’t see the inner workings. To avoid this, the research team will be sharing the code with other engineers—not only cracking open the black box, but allowing the code to be built on and applied to other applications.


  • Scripts and algorithms can help us to close the gap between design and documentation. We developed an algorithm able to formulate and check emergency lighting layouts for Revit spaces, saving cost and time.
  • 'Black box' technologies are common in the industry. By opening the box through using open source knowledge we can shift towards collective responses, ideas and improvements.
  • Research projects don’t have to be big to have a large effect. In this case, a three hour job has been shaved down to 15 minutes.

This story was written by Jeff McAllister, as part of the Research Review. This series is produced by the Arup Australasia Research team; Alex Sinickas, Bree Trevena and Jeff McAllister with contributions from Sheda and Noel Smyth.

Lead Arup Researcher

Justin Szabo
Justin is an electrical engineer with our buildings team in Melbourne.

Ask Justin about

  1. The details on the software and coding he used for this case study
  2. The many other automation projects that he and his team have done since
  3. Where he sees automation and inter-operability going in future building design


Research TEAM

David leads our building services teams.
Dan Candy is an electrical engineer with our Melbourne Buildings team.

Have a problem or a project?

We work with industry partners, governments, universities, startups and community organisations. We do this through research partnerships, and as consultants and facilitators for foresight, research, storytelling and technical writing workshops.

research with us