CodeBook libraries have insighted much opinion and debate over the years, in this post I'll touch on some of the history, what is available now and what makes a good library in my opinion.
Back in my day...
When I first started using CodeBook in 2003, it came with a library database built on the ADB briefing system and an image library of microGDS or AutoCAD blocks. At the time we had 3 major projects running simultaneously in AutoCAD, with each of them using a different briefing system - ADB, Hiltron and Healthcare Environments (HCE). Once we started to develop our exemplar rooms, we soon realised that the 'out-of-the-box' CodeBook library didn't contain everything that we needed and we would need to create project specific content. Also some of the existing blocks, weren't drawn in the way we wanted and so also required some attention.
Naturally each of these projects had their own project database and library, their own set of exemplar room layouts and after drawing equipment and room layouts 3 separate times with only minor differences between them we thought - there has to be a better way! At first the questions were - why doesn't CodeBook provide a decent library? Why are the blocks drawn so badly? I'm sure that I asked Peter these questions quite directly and probably a bit rudely on several occasions.
To his credit and in his usual style Peter explained politely, calmly and succintly that each practice does things differently, each project has different requirements and that he could spend the rest of his life drawing content and still not make everyone happy. Shortly after this he created a new build for me, which added additional fields in the database for different briefing systems (cwfCode2, cwfCode3 and cwfCode4) and enabled us to have an ADB, Hiltron and HCE code neatly sat in parrallel with each other all linked to the same CAD graphic.
The issue of library content had still not gone away though and so myself and a colleague decided to tackle the issue head on and organised a meeting between ADB, Hiltron and HCE. Peter also attended along with a few other architects and service engineers. There was hot debate about industry standards, what wasn't being provided and the lack of content sharing between the various parties. Unfortunately, the differing commercial interests of each party meant that the idea never really gained traction, despite the good intentions.
So whilst being a little disheartened, we decided to consolidate the libraries from these 3 major projects into our very own practice library ready for whatever future project came up, regardless of the briefing system used. This was very powerful and we also picked out the best exemplar rooms from each project and made them into assemblies ready-to-go on the next project. We still felt there was something missing though, as we had lots of individual room data templates (design, finishes, m&e) and assemblies which, on a large project, were very difficult to coordinate and manage. Soon enough, we had another new CodeBook build to try out which introduced Room Types and combined all of these separate templates, plus more.
I learned some valuable lessons back then and working together with Peter, gave us great results. Fast forward to 2011, Revit and Australia and I find that I'm having similar conversations with people albeit several years later on the other side of the world.
So what is available now and what makes a good library?
The standard CodeBook libraries offer both UK and Australian room data sheet templates and provides an AutoCAD library that can be converted into Revit families or A.N.Other platform. There is also now quite a lot of free content available on-line in the form of sketchup models or Revit families. The more astute manufacturers are starting to understand the benefits of modelling their products in Revit and making them available to the industry. Manufacturers producing these aesthetically pleasing accurate families, with O&M manuals and other FM data are already standing themselves apart from their competitors.
There are also companies whose core business is building families and generally speaking these are available for a reasonable price, but you are licensing the right to use the family - not the IP or the exclusive use of it. Not a problem for many practices, but there is yet a further option for the more discerning Revit user - to outsource the creation of your very own custom built library to India or Asia, where you can specify your requirements and have your families built cheaper than you could do in your own studio.
But with all of the above, you need to understand what it is that you are loading into your models and using in your documentation. What is the right level of detail (LOD)? Are the families dimensionally correct? Do they comply with local regulation? The responsibility for this has to remain with the party producing the model or drawings in my opinion and not necessarily the person who produced the family.
Many people think that you can start a project with an "off the shelf library", that will not require any editing throughout the duration of the job. The reality is that you will always have project specific content and each client will want to see greater or lesser detail, descriptions, groupings or coding systems than you currently have. Personally speaking I think investing resources into creating a generic library and then resisting the temptation to make it bespoke for as long as possible is a sound strategy.
At my practice we have made this investment and are now starting to realise the benefits of this work, plus have avoided large volumes of work duplication. In addition, we are generating a series of generic rooms and room data sheets with the goal that each project uses this as a starting point and, through the design development stage, update these to suit specific project / client requirements.
The concept is really quite simple, start from a point of compliance and don't re-invent the wheel each time you start a new project - however - many practices struggle to understand the value of this 'non-project-specific' work, or comprehend sufficiently enough to fund it. This really makes it a strategic matter and if a practice is serious about BIM and Healthcare, they will need to invest money and resources which cost in the short term, but will provide efficiencies in the future.
In addition to creating families and room assemblies, we've also spent considerable time reviewing the data component, in that we have several coding systems sat in parallel, complete with group, class and numerous other properties. These equipment properties are mapped to a corresponding Revit Equipment Parameter, contained within a Shared Parameter file, so that we have continuity and achieve synergies across multiple projects and studios.
Content sharing has been a hot topic of debate and whilst I'm a supporter of the ideal, I'm still uncertain of how it would work in practice. For example, if we were to give our library to another practice, they could not utilize it in the same way that we do in a 'plug-and-play' fashion. Why? Because it is setup to work in our Revit environment and is based on the criteria that we selected. Most practices will have similar requirements, but the naming conventions we use, the coding, description, equipment parameters, revit schedules, views and other 'template' related items will differ and so other than providing a visual representation, using someone else's library has limited value.
To summarize, some of the main elements that make a good library are:
1. Compliance with local standards
2. The correct LOD - i.e. don't model the nuts & bolts, just the general form.
3. Flexibility
4. Equipment data, and last but by no means least
5. Guidance material
You can have the best library in the world, but if no-one knows what it contains or how to use it.....maybe that's why you're reading this blog now!
There are many other parts to this issue, parameter mapping, types & catalog files, reports, legends etc... which I'll cover in separate posts.
...aimed at educating, promoting good practice and demystifying the use of CodeBook within Architecture.
Wednesday, 14 September 2011
Saturday, 10 September 2011
Starting a new project
There are differing lines of thought relating to project setup and configuration, unfortunately there is not a single strategy, but there are some key principles to consider which will guide you though a methodical thought process.
The first relates to project scale. What is the overall square meterage? How many buildings make up the scheme? What is the project build cost? How many departments are there?
Let's take the fictitious example of a 20,000m2 hospital, comprised of a new main hospital building, a new separate clinical services building and a small existing building to be refurbished. The project build cost might be in the region of $100 million, lets say there are 30 departments and lets be nice and give the project a name too - Opera Hospital.
Within CodeBook we have databases, sectors, departments and floors to organize and use to order and group together our rooms. There may also be a Schedule of Accommodation (or Space Programme) to be taken into account when structuring your CodeBook project. We also have the option to assign a room category, which is yet another useful way to group related rooms but we'll come back to this later.
So how many databases will I need? Well, this depends on two other key factors, how will the Revit models be organised and how many CodeBook users will there be?
Based on our example, the Opera Hospital, the project would most likely have three Revit Architectural model files, one for the Main Hospital building, one for the Clinical Services building and one for the existing building that is going to be refurbished. You can of course have a single central model file, containing everything and that every user accesses, but from a practical model management perspective it would probably make sense to split into a series of linked model files. Perhaps you might also have a separate site model, structural model for each of the new buildings and there may also be various consultant models.
The architectural team for Opera Hospital will of course vary depending on the services being offered, resources available and programme, but it would seem reasonable to assume a team size of eight people. This would include a project director, project manager, architects, medical planners and architectural technicians and of this team you might have three staff using CodeBook on a daily basis, the project manager occasionally and perhaps even your client periodically.
One approach would be to have a single CodeBook project database with three sectors, one for the Main Hospital, Clinical Services and Existing building. Each sector would be sub-divided into departments and floors and the departments linked to the appropriate Revit model. The room category is typically used to delineate between clinical, clinical support, general support, administration etc... the beauty of room categories is that they allow you to group rooms across different departments and you can have as many or as few category types as you see fit. If you map these CodeBook fields to a Revit room parameter, you can synchronise the data to your model and build views upon them, which can be a powerful tool and provide a visual representation of your schedule of accommodation (space programme).
This arrangement would provide a good basis to start the Opera Hospital project from and by having a single database, it means that you only need setup the project properties, parameter mapping, reporting formats etc... once, rather than several times had you started off with multiple databases. It is possible to copy settings from one project database to another, but if you can avoid the extra work of coordinating multiple databases and updating them, then why wouldn't you?
Well, one potential reason is the size of the project database and another is the number of users accessing, editing, updating and reporting from it. Technically you can have any number of users working in a single project database at the same time, but from a practical perspective it sometimes makes sense to split files up to avoid the performance of the whole team being adversely affected.
Generally speaking I try to keep project database filesize under 15mb, I've found that project databases larger than this, suffer from at least one of the following:
_as an attachment, the project database is too large for some email systems
_the users may notice performance issues, i.e. how long it takes to perform a task
_users often "bump into each other", i.e. one person is synchronising, whilst another is linking rooms, or updating designed equipment, or running a report...
Databases will allow multiple users to access them simultaneously, but if one user has a room open, whilst another user synchronises the same room, whilst a third user tried to update designed equipment for the room - what do you think might happen? The likelihood is that at least one of these processes would not complete fully, or worse still the program might crash. Databases use record locking, a similar concept to Revit worksets, and this generally applies at the room level of granularity.
Through each project phase, the Opera Hospital will amalgamate more and more information, room data sheets will be completed, detailed construction information added and costing, procurement and FM data may be included towards the end of the architectural teams involvement. The usage and demand of users accessing CodeBook will change during the project lifecycle, so it is quite likely that you may start with a single project database, but this may be sub-divided once you get into the design development stage. It is also quite feasible that your client will want a single consolidated view of the project at key project milestones and upon handover, which will require you to merge back together your project database files.
Reviewing the demands of the project regularly and considering the needs of the team using CodeBook is essential to the health of your project files. In summary the sort of questions you should consider are:
1) What is the scale of the project?
2) How many users will be accessing the CodeBook files?
3) How many Revit models are there containing Revit rooms and families?
4) Will these requirements change in the next few months?
This should help you determine the best way to organise your CodeBook files, but remember files can quite easily be split and merged back together, although I wouldn't advise doing this on a regular basis. Before making a significant change to your structure, speak with other members of the project team, the BIM/model manager and take a backup so that you can revert back if needed.
I'll cover splitting and merging databases in a subsequent post, plus backups and archiving.
The first relates to project scale. What is the overall square meterage? How many buildings make up the scheme? What is the project build cost? How many departments are there?
Let's take the fictitious example of a 20,000m2 hospital, comprised of a new main hospital building, a new separate clinical services building and a small existing building to be refurbished. The project build cost might be in the region of $100 million, lets say there are 30 departments and lets be nice and give the project a name too - Opera Hospital.
Within CodeBook we have databases, sectors, departments and floors to organize and use to order and group together our rooms. There may also be a Schedule of Accommodation (or Space Programme) to be taken into account when structuring your CodeBook project. We also have the option to assign a room category, which is yet another useful way to group related rooms but we'll come back to this later.
So how many databases will I need? Well, this depends on two other key factors, how will the Revit models be organised and how many CodeBook users will there be?
Based on our example, the Opera Hospital, the project would most likely have three Revit Architectural model files, one for the Main Hospital building, one for the Clinical Services building and one for the existing building that is going to be refurbished. You can of course have a single central model file, containing everything and that every user accesses, but from a practical model management perspective it would probably make sense to split into a series of linked model files. Perhaps you might also have a separate site model, structural model for each of the new buildings and there may also be various consultant models.
The architectural team for Opera Hospital will of course vary depending on the services being offered, resources available and programme, but it would seem reasonable to assume a team size of eight people. This would include a project director, project manager, architects, medical planners and architectural technicians and of this team you might have three staff using CodeBook on a daily basis, the project manager occasionally and perhaps even your client periodically.
One approach would be to have a single CodeBook project database with three sectors, one for the Main Hospital, Clinical Services and Existing building. Each sector would be sub-divided into departments and floors and the departments linked to the appropriate Revit model. The room category is typically used to delineate between clinical, clinical support, general support, administration etc... the beauty of room categories is that they allow you to group rooms across different departments and you can have as many or as few category types as you see fit. If you map these CodeBook fields to a Revit room parameter, you can synchronise the data to your model and build views upon them, which can be a powerful tool and provide a visual representation of your schedule of accommodation (space programme).
This arrangement would provide a good basis to start the Opera Hospital project from and by having a single database, it means that you only need setup the project properties, parameter mapping, reporting formats etc... once, rather than several times had you started off with multiple databases. It is possible to copy settings from one project database to another, but if you can avoid the extra work of coordinating multiple databases and updating them, then why wouldn't you?
Well, one potential reason is the size of the project database and another is the number of users accessing, editing, updating and reporting from it. Technically you can have any number of users working in a single project database at the same time, but from a practical perspective it sometimes makes sense to split files up to avoid the performance of the whole team being adversely affected.
Generally speaking I try to keep project database filesize under 15mb, I've found that project databases larger than this, suffer from at least one of the following:
_as an attachment, the project database is too large for some email systems
_the users may notice performance issues, i.e. how long it takes to perform a task
_users often "bump into each other", i.e. one person is synchronising, whilst another is linking rooms, or updating designed equipment, or running a report...
Databases will allow multiple users to access them simultaneously, but if one user has a room open, whilst another user synchronises the same room, whilst a third user tried to update designed equipment for the room - what do you think might happen? The likelihood is that at least one of these processes would not complete fully, or worse still the program might crash. Databases use record locking, a similar concept to Revit worksets, and this generally applies at the room level of granularity.
Through each project phase, the Opera Hospital will amalgamate more and more information, room data sheets will be completed, detailed construction information added and costing, procurement and FM data may be included towards the end of the architectural teams involvement. The usage and demand of users accessing CodeBook will change during the project lifecycle, so it is quite likely that you may start with a single project database, but this may be sub-divided once you get into the design development stage. It is also quite feasible that your client will want a single consolidated view of the project at key project milestones and upon handover, which will require you to merge back together your project database files.
Reviewing the demands of the project regularly and considering the needs of the team using CodeBook is essential to the health of your project files. In summary the sort of questions you should consider are:
1) What is the scale of the project?
2) How many users will be accessing the CodeBook files?
3) How many Revit models are there containing Revit rooms and families?
4) Will these requirements change in the next few months?
This should help you determine the best way to organise your CodeBook files, but remember files can quite easily be split and merged back together, although I wouldn't advise doing this on a regular basis. Before making a significant change to your structure, speak with other members of the project team, the BIM/model manager and take a backup so that you can revert back if needed.
I'll cover splitting and merging databases in a subsequent post, plus backups and archiving.
Wednesday, 7 September 2011
Upgrading a v8.2 dataset to v9
The process to upgrade a v8.2 dataset to v9 is very straightforward, but before doing so, take a moment to think through the pros and cons because once you have upgraded the data you will no longer be able to open it with v8.2
Generally speaking you should find more positives than negatives, but perhaps you're locked into an older CAD format (<2008) for the project by your client and that format is not supported by v9? The project is almost completed and v8.2 is doing everything you require? Other members of the design team are using v8.2? You're providing the CodeBook database files to your client, which they are plugging into their own systems?
None of the above are a showstopper, but think it through first, take a backup of your files and talk to others.
OK, so the process for upgrading your v8.2 data to v9 is simply:
1. Run the file 'CodeBook_v82_data_upgrade.exe'
2. You'll be asked to select the CodeBook project database you want to upgrade
3. Then you'll be asked to select the Codebook library that you want to upgrade
...refer to CIS-56 for more information...
Once you've run through this process, fire up CodeBook v9 and take a look!
One of the main differences between the versions is that in v8.2 all of the lookups, room data templates, equipment and assemblies were stored in a single library database. CodeBook has evolved substantially during the last few years and storing the lookups and room data templates in one database (CDEB_RmDataLib.mdb) and the equipment and assemblies in another (CDEB_EquipLib.mdb) made sense for many reasons. The v9 library files are more portable, arguably there are performance advantages and now there are many more options and possibilities regarding equipment and it's associated data.
So when you run the 'CodeBook_v82_data_upgrade.exe' what is happening in the background is that your equipment library is being split into two databases one containing room data information and one containing equipment.
The CodeBook project database and library are still connected through linked tables and most users won't notice any real difference other than having to select the location of the Equipment library and also having to select the location of the Room Data library upon opening a project for the first time in v9.
Generally speaking you should find more positives than negatives, but perhaps you're locked into an older CAD format (<2008) for the project by your client and that format is not supported by v9? The project is almost completed and v8.2 is doing everything you require? Other members of the design team are using v8.2? You're providing the CodeBook database files to your client, which they are plugging into their own systems?
None of the above are a showstopper, but think it through first, take a backup of your files and talk to others.
OK, so the process for upgrading your v8.2 data to v9 is simply:
1. Run the file 'CodeBook_v82_data_upgrade.exe'
2. You'll be asked to select the CodeBook project database you want to upgrade
3. Then you'll be asked to select the Codebook library that you want to upgrade
...refer to CIS-56 for more information...
Once you've run through this process, fire up CodeBook v9 and take a look!
One of the main differences between the versions is that in v8.2 all of the lookups, room data templates, equipment and assemblies were stored in a single library database. CodeBook has evolved substantially during the last few years and storing the lookups and room data templates in one database (CDEB_RmDataLib.mdb) and the equipment and assemblies in another (CDEB_EquipLib.mdb) made sense for many reasons. The v9 library files are more portable, arguably there are performance advantages and now there are many more options and possibilities regarding equipment and it's associated data.
So when you run the 'CodeBook_v82_data_upgrade.exe' what is happening in the background is that your equipment library is being split into two databases one containing room data information and one containing equipment.
The CodeBook project database and library are still connected through linked tables and most users won't notice any real difference other than having to select the location of the Equipment library and also having to select the location of the Room Data library upon opening a project for the first time in v9.
Tuesday, 6 September 2011
Installing CBv9 for Revit 2011 & Revit 2012
Much of this post is stating the obvious, but for new users, CodeBookers who don't typically install software and IT departments who don't use Revit or CodeBook and normally run a single installation file - it might be useful.
CodeBook Information Sheet #55 (CIS-55) will walk you through the step by step process for installing the software, but there are a few key points worth highlighting that may save you a call to CodeBook support!
1. Before you are ready to install CodeBook, you must first:
a) purchase a license
b) download the installation files
c) download the Sample Project Revit files, ('CdeB_MasterLib_V9_Revit' & 'Sample Project v9 Demo')
d) have administrator rights to the PC you are installing the software onto
...for local resellers, see the links on the right hand navigation...
2. Installation files that need to be run are:
a) CodeBook_v9.msi (installs the software)
b) CodeBook_x64Service.msi (MS Access = 32 bit, Revit = 64 bit so this service enables Access and Revit to communicate)
3. License server, the process to obtain a license is:
a) fire up CodeBook
b) enter your 'company reference' (provided when you purchased the software)
c) register a 'New User'
d) check your email for the confirmation code from Nitromation (Nitromation provide the license manager server)
e) copy and paste your confirmation code into the CodeBook login screen
f) click 'Obtain License'
...keep going, almost there...
4. Start CodeBook v9, assuming you've never used the software before you should:
a) Create a new project
b) When asked to select an existing project to use as a template > path to the location where you saved the Sample Project Revit files
c) You'll be prompted to save your new project, and then
d) Confirm the location of the Equipment and Room Data Libraries > again path to the location where you saved the Sample Project Revit files
...if you have used CodeBook before and want to upgrade from a previous version, see the post Upgrading a v8.2 dataset to v9...
5. Revit to CodeBook command path - final step!
a) Select File > Project Properties...
b) Expand the Administrator > CAD and BIM Settings section and click on Revit
c) In the Codebook to Revit command path check the path and location of the 'CodeBook.Addin' file
For this last part, if you have a standard, out-of-the-box installation of Revit, you may choose to keep the CodeBook default location:
'C:\Users\xxx your username xxx\AppData\Roaming\CodeBook Data'
The chances are you'll have some Revit customisation, so you will need to check that you have the CodeBook.Addin file saved into your Revit Addins folder and that you have entered this location in the 'Codebook to Revit command path'.
For example, we use various Revit Add-ins, such as Worksharing Monitor, Model Review, Bluestreak etc... accessed through the Revit Addins ribbon and these are all saved into:
'C:\ProgramData\Autodesk\REVIT\Addins\2011'
Congratulations - you've now successfully installed and configured CodeBook to work with Revit!
I'll cover Project & Library setup in a subsequent post.
Revit Architecture 2011 or 2012 and the Microsoft Access version of CodeBook will be used by most of the industry, but I'll keep an eye out for requests to explain the install process for other software packages or releases...
CodeBook Information Sheet #55 (CIS-55) will walk you through the step by step process for installing the software, but there are a few key points worth highlighting that may save you a call to CodeBook support!
1. Before you are ready to install CodeBook, you must first:
a) purchase a license
b) download the installation files
c) download the Sample Project Revit files, ('CdeB_MasterLib_V9_Revit' & 'Sample Project v9 Demo')
d) have administrator rights to the PC you are installing the software onto
...for local resellers, see the links on the right hand navigation...
2. Installation files that need to be run are:
a) CodeBook_v9.msi (installs the software)
b) CodeBook_x64Service.msi (MS Access = 32 bit, Revit = 64 bit so this service enables Access and Revit to communicate)
3. License server, the process to obtain a license is:
a) fire up CodeBook
b) enter your 'company reference' (provided when you purchased the software)
c) register a 'New User'
d) check your email for the confirmation code from Nitromation (Nitromation provide the license manager server)
e) copy and paste your confirmation code into the CodeBook login screen
f) click 'Obtain License'
...keep going, almost there...
4. Start CodeBook v9, assuming you've never used the software before you should:
a) Create a new project
b) When asked to select an existing project to use as a template > path to the location where you saved the Sample Project Revit files
c) You'll be prompted to save your new project, and then
d) Confirm the location of the Equipment and Room Data Libraries > again path to the location where you saved the Sample Project Revit files
...if you have used CodeBook before and want to upgrade from a previous version, see the post Upgrading a v8.2 dataset to v9...
5. Revit to CodeBook command path - final step!
a) Select File > Project Properties...
b) Expand the Administrator > CAD and BIM Settings section and click on Revit
c) In the Codebook to Revit command path check the path and location of the 'CodeBook.Addin' file
For this last part, if you have a standard, out-of-the-box installation of Revit, you may choose to keep the CodeBook default location:
'C:\Users\xxx your username xxx\AppData\Roaming\CodeBook Data'
The chances are you'll have some Revit customisation, so you will need to check that you have the CodeBook.Addin file saved into your Revit Addins folder and that you have entered this location in the 'Codebook to Revit command path'.
For example, we use various Revit Add-ins, such as Worksharing Monitor, Model Review, Bluestreak etc... accessed through the Revit Addins ribbon and these are all saved into:
'C:\ProgramData\Autodesk\REVIT\Addins\2011'
Congratulations - you've now successfully installed and configured CodeBook to work with Revit!
I'll cover Project & Library setup in a subsequent post.
Revit Architecture 2011 or 2012 and the Microsoft Access version of CodeBook will be used by most of the industry, but I'll keep an eye out for requests to explain the install process for other software packages or releases...
Subscribe to:
Posts (Atom)