The Berkeley Marvell NanoLab: Powered by Actian X
The University of California, Berkeley Marvell Nanofabrication Laboratory (NanoLab) is a 15,000 square-foot state-of-the-art cleanroom facility with a wide range of micro- and nanofabrication capabilities. The NanoLab is open to any academic researcher and has members from across campus as well as visiting scientists from other universities, national laboratories, and local industry. Recharge revenues for the use of its resources amounted to $4.5 million in FY2018-2019.
When it comes to pure science excitement, not many places can top the Marvell Nanofabrication Laboratory (NanoLab) at the University of California, Berkeley. It’s a 15,000 square-foot state-of-the-art cleanroom facility designed to facilitate the development of next-generation microelectronics, optoelectronics, superconducting devices, micro- and nano-electromechanical systems, miniaturized integrated sensor platforms, and more. It’s available 24-7 to some 450 researchers from academia, national laboratories, and local industry.
And access it they do: During the 2018-2019 academic year, researchers logged more than 60,000 hours in the lab. But therein lies a challenge, too: The technologies available to researchers are in high demand—e-beam nanolithography writers (50kV and 130 kV), step-and-repeat reduction cameras (365nm i-line and 248nm deep-UV), a 375nm direct-write laser patterning system, a 4″/6″ silicon wafer processing area with LPCVD and atmospheric furnaces, process-specific plasma etchers, wet processing stations, and much more—but are not present in high quantities. Two of these, one of those, maybe three of another. Time on each system must be scheduled in advance; calibration and maintenance efforts have to be conducted routinely and at times when the equipment is least in demand. Parts and supplies must be stocked; accounts must be kept; usage must be billed.
Management of this sophisticated lab was not going to be left to chance: Early in the development of the NanoLab, the lab leadership team decided to build its own laboratory management system (LMS). For flexibility, reliability, and high performance, developers wanted to build the LMS around a database, and the one they ultimately chose provided a combination of flexibility, reliability, and high performance befitting the sophistication of the laboratory it was intended to support: the database now known as Actian X.
The LMS powering the NanoLab can trace its history to the early ’80s when researchers at Berkeley developed the Berkeley Computer Integrated Manufacturing System (BCIMS). This was an integrated set of more than 200 distinct programs all running on a UNIX operating system with a terminal-based interface called The Wand. All these programs stored their activities in the underlying Ingres relational database—a well-regarded database platform also developed at Berkeley. The Wand and Ingres powered the predecessor of the NanoLab, the Berkeley Microlab, for more than 20 years.
In the late ‘90s, it was time to plan for the next generation laboratory and it would need a next generation LMS. Berkeley developers started collaborating on a system with their counterparts in labs run by Stanford and MIT. Over time, though, the developers at Berkeley chose to move in a different direction. “Berkeley elected not to continue with this group effort,” says Dr. Bill Flounders, Executive Director of the NanoLab. “At the time, there were no turnkey laboratory management software solutions available, but we considered the target product that Stanford and MIT were developing to be too generic for best management of the Berkeley facility.”
Utilizing the best tools and techniques available, the developers at Berkeley went on to create their own LMS, Mercury. Given the developers’ familiarity with the power and flexibility of the Ingres relational database, Ingres was the natural choice for use in this powerful new laboratory management system.
While Ingres changed hands and names over the course of time—today it is known as Actian X—its critical role at the heart of Mercury has not changed. The database has been updated regularly—the NanoLab is now running Actian X v11— but there has never been any need or desire to supplant it as it continues to provide the performance, flexibility, and reliability that the NanoLab requires. And that’s been true even as the needs of the NanoLab have themselves evolved.
“Actian X is the backbone of Mercury,” says Dr. Flounders. “It controls all aspects of the NanoLab: accounting, chemicals and parts inventories, purchasing, member administration, tracking cleanroom and equipment use, equipment and utility problem reports, online tests/qualifications, cleanroom environment (temperature, humidity, air flow), specialized utilities (deionized water system, specialty gases), monitoring and alerts, even machine shop job assignment, tracking, and billing.”
Indeed, what started as a (relatively straightforward) laboratory management system has evolved over time. NanoLab developers extended the original LMS functionality of Mercury to incorporate the functionality required for machine shop management and subsequently extended it again to accommodate the functionality required to support broader utility management. “New modules are being developed and added regularly,” says Dr. Flounders. “This year we added the gas cylinder management program. Next year, we release Mercury X which will be a full overhaul of the graphical user interface, but it will still be Actian X providing the foundation.”
The Mercury system itself is written in Java, with a web interface (which researchers can access from anywhere in the world) written using the JavaServer Faces (JSF) application framework. The underlying Actian X database, running on Red Hat Linux, includes two live databases containing more than 300 tables. One table holds more than 11 million rows of data by itself. Mercury also maintains a third database in Actian X for historical data. It is not actively updated but is often consulted when historical insights are needed.
Because of Mercury’s central role in the delivery of services within the NanoLab, the Actian X database is crucial to smooth operations. Indeed, every functional aspect of Mercury—from accounting and purchasing to inventories and equipment use to utility systems monitoring, problem reporting and tracking, and job tracking—involves one or more interactions with Actian X, so the database must deliver ongoing reliability and high performance.
And that it does.
“Actian X provides us with a stable, well-supported relational database management system,” says Computer Systems Manager Olek Proskurowski. “It is powerful, dependable, and easy to administer, so we can essentially start it and forget about it. It just doesn’t need ongoing attention. Even patch management and upgrades to new versions of Actian X do not require a lot of effort.”
The benefits of Actian X extend well beyond transactional matters such as scheduling equipment and charging for services. Actian X also enables NanoLab planners to analyze tool usage and utility dependencies throughout the lab. By monitoring for utility consumption spikes, NanoLab engineers have been able to spot malfunctioning equipment quickly. The accounting team can also access detailed historical billing records from the Actian X database which they can use to model the impact of new lab recharge rates. “We can access all the usage data from a previous fiscal year to estimate revenue gain or loss based upon changes to multiple lab recharge rate categories,” says Dr. Flounders.
Indeed, as an LMS, the combined power of Mercury and Actian X has proven its value time and again at the NanoLab—so much so that other labs on campus have been making inquiries about the possibility of using the system to manage their operations. The opportunities are not lost on Dr. Flounders and the computer team.
Says Dr. Flounders, “we have analyzed Mercury to determine which aspects of the solution are unique to the NanoLab and which are common to other environments—and separated our system into group functionalities accordingly. The core functions would be valuable to a wide range of facilities, and we’re looking at offering a version of Mercury that delivers that functionality. There are specialized functions that are unique to our facility and unlikely to be offered in a separate module, but there are still other functions that we’re planning to incorporate in future versions of Mercury that may well be of general interest and could be added to the module we offered to others. Mercury and Actian X certainly work well for us; we imagine they would work quite well for others, too.”