Building a Smart Laboratory 2012 Technical issues
Technical issues
Information and Communication Technology (ICT) democratises innovation and enables smaller companies, academia and students to get access to computing that was previously only available to large organisations. However, adopting new computer and infrastructure technologies in labs only makes sense if it results in better and more productive scientific operations. Te rapidly changing field of ICT can be
overwhelming. Laboratory work is becoming increasingly collaborative and complex, leveraging multiple technologies to improve scientific measurement techniques and scientific understanding. Tis exponential rise in the scale of data being generated, combined with the increased collaboration, has resulted in a need to rethink how data is stored, analysed and shared cost-effectively. Te primary requirement for the
deployment of lab informatics systems is that they can be integrated within the organisation’s existing IT infrastructure. Te IT department will be able to advise how this can be achieved and how the proposed solution will integrate with existing investments. Tere are a number of factors to be taken into consideration in the broader set of requirements. It will be important to take geographical distribution into consideration. In wide
area networks, latency becomes the most noticeable issue and acceptable maintenance windows may disappear if the implementation extends over multiple time zones. In time, the system will need to accommodate growing volumes of data, both in terms of the number of data items and the size of individual data items. Additionally, the number of users will generate more disparate requirements, not the least of which is the concern of how many people will get upset if the system goes down.
Systems architecture
Multi-user informatics systems are typically based on two- or three-tiered structures in which the application soſtware and database may share a server, or be located on separate servers, with the client-side soſtware deployed on a local desktop, laptop or mobile device. Traditionally, the servers are based in-house, but hosted services (cloud/SaaS) are generating increasing interest, based on potential business benefits. From the user perspective, the client-side
options fall into the following categories: thick-client and thin-client. Te thick client is usually a substantial soſtware installation on a local computer in which a good deal
of the data processing is undertaken before passing the output to the database server. Tis has the advantage of distributing the total processing load over a number of clients, rather than the server, and may also allow a certain amount of personalisation of the client soſtware to support individual users’ needs. Te downside is that system upgrades
can become time consuming and potentially troublesome depending on the local configuration, although centrally-managed systems are now making thick client systems easier to deploy, maintain and support. Tin clients typically access the
application and database server(s) through a browser. No local processing power is used, so the server and network performance are critical factors in providing good performance. Te use of a browser eliminates deployment and upgrade costs, but may restrict or limit user configurability. With regard to devices, successful
deployments have been made with small form-factor PCs on the laboratory bench, remote desktop, Citrix and a KVM switch operating between a desk-bound processor unit with keyboards and screens on the desk and in the laboratory. Mobile devices, such as tablets, laptops and smartphones, have been less successful
25
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36