A lens is an optical element having axial symmetry and at least one curved surface whose function is to converge or diverge light. The word 

 comes from the genus name of the lentil (

), whose shape the common lens mimics. A simple lens is composed of one piece of material, while a compound lens has more than one piece of material, which can be desirable for several reasons.  

A lens must have at least one curved surface, which usually has the shape of an arc of a sphere (hence, called a spherical lens). Having said that, there are several combinations of curved and uncurved (flat) surfaces that can make a lens. Both surfaces can be convex, making a convex lens. One surface can be convex and the other flat, making a plano-convex lens. One side can be convex and the other concave; depending upon which surface has the greater curvature, the lens can be either positive meniscus or negative meniscus. If one side is flat and the other concave, the lens is plano-concave. A biconcave lens has both sides concave. These possibilities are shown in Figure 1. Lenses can have surfaces that are arcs of different curves, like parabolas or hyperbolas. Here, we will focus on just the spherical convex and biconcave lenses.  

Likely the most recognizable lens, a convex lens acts to converge light. Parallel rays of light entering a lens will all meet at one point on the other side of the lens. The distance between the center of the lens and this meeting point is called the focal length (Figure 2). For a thin lens (in which the thickness of the lens is negligible compared to the radius of curvatures), the focal length can be determined by the curvature of the two sides of the lens. If the radii of curvature of the two surfaces are 

 and the index of refraction of the lens material is 

 is related to these quantities by the equation  

In determining the focal length, it is important to observe the proper convention for the signs of 

 is positive for convex surfaces and negative for concave surfaces, while for 

, the sign is negative for convex surfaces and positive for concave surfaces.  

If light striking a point of an object farther than the focal length on one side of a thin convex lens passes through the lens, the light from that point will converge onto a point on the other side of the lens. Light from all points of an object thus focuses on a similar set of points on the opposite side of the lens; we say an image of the object is formed. This is shown in Figure 3a. In this case, the image is referred to as a real image; a screen placed at the position of the image will show a replication of the original object, which is the basis of photography. For a thin convex lens having focal length 

, the relationship between the distance of the object to the lens 

 and the distance of the image to the lens 

This expression is called the thin lens formula. By convention, 

If the object is inside the focal length, then light rays emanating from a point do not come to a focus on the other side of the lens, but rather, they diverge. This is shown by the colored arrows in Figure 3b. Projecting the diverging light rays back to their focus, we note that the image we see, a virtual image, is larger than the original object. As such, in this circumstance, a convex lens provides magnification of objects. The formula for calculating the magnifying power 

 is now negative. Magnifying glasses, for example, work on this principle. 

If a lens is concave, parallel light coming into it is diffracted away from the axis of symmetry: it is a diverging lens (Figure 4). The parallel light appears to be coming from a focus 

 that is behind the lens, which is described as having a negative focal length 

Concave lenses also can be used with images, but in these cases, the images will always be virtual and will be smaller than the original image (minification). Figure 5 illustrates how light rays from a point of an object are affected by the lens.  

Meniscus lenses behave overall like the surface that has the smaller (that is, steeper) radius of curvature. Thus, negative meniscus lenses behave overall like concave lenses, while positive meniscus lenses behave like convex lenses. 

A cylindrical lens is a lens that focuses parallel light into a line rather than a point. Typically, it has one flat surface and one curved surface, mimicking the surface of a cylinder (Figure 6a). Aspheric lenses are lenses whose curved surface does not follow a spherical arc (Figure 6b). A compound lens is composed of more than one lens, usually of different types or materials (Figure 6c). The individual lenses either are glued together with Canada balsam or epoxy or are mounted sturdily with an air gap in between them.  

A very interesting lens is the Fresnel lens (Figure 6d), named after the French scientist Augustin-Jean Fresnel (frey-NELL). In a Fresnel lens, each concentric segment (called a Fresnel zone) has a curved surface with the same radius of curvature, but is offset inward at certain radii. This allows the construction of larger lenses without using substantially more material (compare the size of Figure 6d with the plano-convex lens in Figure 1), although early Fresnel lenses were made of multiple individual components and not a single piece. Because the lens was thinner, attenuation of light due to lens material was much less, allowing for brighter light intensity. Fresnel lenses found particular application in lighthouses, where their increased output allowed ships to see them from farther distances. 

Despite the equations given earlier and the figures presented now, lenses are not perfect. They present certain imperfections that either limit their usefulness or require some sort of correction to improve their function. 

There are several types of aberration. Spherical aberration arises from the fact that a spherical surface is not the ideal surface needed to focus all parallel light to a sharp focus. Generally speaking, the farther away from the lens axis, the closer the light is focused (Figure 7a). The result is a "focus" that occupies a finite distance from the lens. Chromatic aberration is caused by the fact that virtually all lens materials refract light of different color by different amounts. As such, light of different colors will focus in slightly different places, and not only will the focus occupy a different distance from the lens, each position will highlight a different wavelength or frequency of light (Figure 7b). Coma (or comatic aberration) is a type of aberration in which light rays come in at an angle to the optical axis. When this occurs, light entering the lens at different distances from the optical axis converges at different points on a focal plane (Figure 7c). If the lens is circular, the focused light marks out a circle of points for each distance from the axis, with the circle getting larger and dimmer as the distance from the optical axis increases. Because the resulting image resembles a comet, the name for this phenomenon derives from the same Latin root.  

Astigmatism is an effect seen when, for a circular lens, focus in one axis is different than the focus in the perpendicular axis. Although we commonly hear about astigmatism when it comes to eyes, optical lenses also can suffer from astigmatism. 

Diffraction limits are one ultimate limitation of lenses. Because lenses are of finite size, they essentially act as a "hole" that light rays pass through. We know from experiments on light going through an aperture that the light waves will diffract, which changes the direction of the light's propagation. As such, an image will not be infinitely sharp, but will experience some amount of blurriness. If we assume that the light waves impinging on the lens are parallel, then the light experiences what is called Fraunhofer diffraction. This diffraction causes a point source to be imaged as a finite-sized image called an Airy disk (Figure 8), which shows bright and dark alternating circular patterns. The radial pattern of intensities is related to a Bessel function of the first kind having order one. (To understand what that means, we would have to get into the mathematics of Bessel functions, which is beyond the scope of this column. Suffice it to say, however, that Bessel functions are well-defined mathematical functions, like sine or cosine, only more complicated.)  

Lenses cannot image items smaller than their Airy disk; lenses that focus up to their Airy disk are called diffraction-limited. As such, it is important to know what the diffraction limit is of any lens. For a lens having a diameter 

 of the first dark circle of the Airy disk is  

where λ is the wavelength of the light and 

 is the focal length of the lens. (The fraction 

-number of the lens, which is a concept well-known to photographers.) 

Diffraction limits demonstrate the inherent maximum ability of a lens to image an object. For example, if your lenses were made of sapphire (pure crystalline quartz), which has a cutoff wavelength of about 142 nm, a microscope having an 

-number of 4 could only image an object of about 1.4 μm or larger. If you want to see something smaller, you are out of luck. The concept of diffraction limits demonstrates the characteristics that make better lenses: lower operating wavelengths (which depend upon the optical characteristics of the lens material), shorter focal lengths, and larger lens diameters (which bring their own problems: very large sizes of large lenses can distort the lens itself!).  

 is a professor of chemistry at Cleveland State University in Ohio. Many of his "Baseline" columns have been reprinted in book form by SPIE Press as 

, available through the SPIE Web Bookstore at 

 (published in May 2006), is available from SPIE Press. He can be reached at 

Articles

Columns: The Baseline

In the last installment of this column, I discussed prisms. In this installment, we will consider their curved cousins.

Lenses

In the first part of this column series on traceability matrices (1), we reviewed a system development life cycle model and then discussed the regulatory requirements and expectations as well as the business benefits of this document. We also looked at the terminology used and some of the principles of tracing requirements to other documents and activities in the life cycle.  

Two points need to be reiterated from Part I for the discussion in this part. Requirements can either be tested or verified throughout the life cycle. 

Testable: The degree to which a requirement is stated in terms that permit establishment of test criteria and performance of tests to determine whether those criteria have been met. This is typically undertaken in the operational qualification (OQ) or performance qualification (PQ) phases of the life cycle. 

Verifiable: The degree to which a requirement can be fulfilled by implementation (in the installation qualification phase), software configuration, writing standard operating procedures (SOPs), user training, vendor audit, calibration, or documentation. 

This is important. In contrast to the GAMP 5 guide (2) that only discusses verification in the testing phases of a life cycle model, I prefer to split traceability into testing and verification because these are different, and in doing so, it makes the process easier and simpler to understand. When I talk about 

, I am referring to tasks that will be undertaken by the user (during the PQ) and also the vendor (during the OQ). In contrast, requirements that are 

 are scattered throughout all the remaining stages of a life cycle and not just the testing ones. 

Linking Requirements with Their Testing or Verification

To illustrate the principles of traceability between the requirements in the user requirements specifications (URS) and testing and verification in later stages of a system life cycle, let's look at Figure 1. The URS and the requirements that it contains are shown in the left-hand column. Across the top of the figure in a single row are the documents that could be written in a validation project. The figure caption lists what each of the abbreviations used in the table means. Before we start our traceability journey, the document names are what I would typically use; your organization might name them differently, but that is not a problem. This is to illustrate the principles of traceability in more detail than in Part I. You will need to interpret this approach using your terminology instead.  

I will discuss the principles of traceability using most of the nine requirements listed in the URS in Figure 1. After the principles have been discussed, you can apply them to the remaining ones.  

Requirement R1 is for the PC hardware upon which the spectrometer software will run and that the IT department will purchase. This is expanded in more detail to the make, model, memory, disk size, and configuration required to support the application and store the acquired data. It is traced first to item the specification T1 in a document called a technical specification; from here it is verified during the installation qualification (IQ) of the computer system. This answers the question: was what we specified actually delivered and installed, and if not, has the difference been documented. 

R2 describes a requirement that needs an SOP written for the users to follow, and when this document is available the requirement will be verified. Collate all the user requirements that trace to procedures, check them against existing SOPs, and update as appropriate. Where no SOP exists, one must be written.  

R3 leads to a function in the application software that will be configured and the setting is documented in the configuration specification in section 3.2 and tested during the PQ (for example, T). One can go further than just listing T under the PQ, but the detail to which we go will be discussed in a later section of this column.  

R4 is a requirement that will be tested adequately during the vendor's OQ execution, and therefore it will not be tested again during the PQ because it concerns resources and effort.  

R6 illustrates an interesting point. A single URS requirement might break down into one or more functional requirements. One of these links to a configuration of the application software, which is then tested, and the other one will be tested directly from the description in the functional specification. 

Some of the other requirements can be verified by calibration of the instrument carried out in the laboratory, a vendor audit of the vendor, or a service-level agreement with IT. Remember, computer validation is only one mechanism of control. Some others are calibration, maintenance, and qualification. 

Figure 1 provides the big picture of traceability – requirements are traced from the URS throughout the whole of the life cycle. However, this figure only goes halfway. Note that the arrows only point one way from the URS to the place in the life cycle where each is either tested or verified. Ideally, traceability should be a two-way process — forward from the URS to other documents as shown in the figure but also from the documents backward to the URS. 

Because this column is about the practicalities of traceability, I'd like to give some examples of how to develop a traceability matrix. However, for reasons of space, I'll not be able to discuss all the options, but I'd like to look at some of the main ones.  

The simplest traceability matrix can be found in the single integrated validation document (3,4). Here, a single document is written for the validation of a system and the traceability is used within the document to link the intended use requirements to where the requirement is tested or verified. This simplified approach can be used for systems that require validation but consist generally of nonconfigurable software (GAMP Category 3) (2). A detailed discussion and examples of the integrated validation document can be found in reference 4.  

In the example presented in Table I, a simplified traceability matrix has been incorporated into the user requirements section of the integrated validation document. The user requirements consist of tables containing three columns. The first column is the unique number of the requirement (in this case generated automatically by Word); the requirement itself is in the second column; and finally, the third column indicates how the requirement will be tested or verified (the traceability matrix). The example given is not from spectrometer software, but is from an application that controls and analyzes data generated by battery-powered data loggers that can be used to monitor temperature in environmental storage or shipping packages from one location to another. The section of the requirements covers the data loggers used by the system.  

Table I: An example of intended use requirements with traceability (4)			

There are two traceability references shown in Table I.  

The first is C against requirements 13–15 inclusive. This refers to traceability to the calibration certificate provided by the vendor with each batch of data loggers. 

The remaining requirements will be tested in the test procedure contained in section 8.2 of the document, which covers the shipping of material from a primary to secondary manufacturing site as outlined in the next section of this article. 

As shown in Figure 1, traceability can be to other phases of the life cycle, writing standard operating procedures or installation of components that will not be illustrated in this example. 

Traceability from the Functional Specification to the URS

The next example is where there needs to be traceability for an NIR spectrometer used for identification of delivered material within a pharmaceutical warehouse. The requirements contained in the URS are being traced into a functional specification. To ensure that all requirements are broken down from the URS to the functional specification (FS), the numbers of each are listed in the two left-hand columns (Table II).  

Table II: Functional specification for an NIR spectrometer used for compound identification			

Note that for three user requirements (5.1.1, 5.2.4, and 5.7.6), these have been decomposed into eight functional requirements in the FS. This is typical as requirements are broken down further and is also depicted in Figure 1 where there is a one-to-many relationship as a requirement moves from the URS to the FS. Alternatively, you can avoid the need to write an FS if your URS is sufficiently detailed.  

Because this is a more complex system, word auto-numbering is not used and each number must be typed into the appropriate column. In fact, word auto-numbering should only be used with the integrated validation document, because traceability is linked directly with the requirement number. In all other cases, it is an indirect link and use of autonumbering will result in destroying traceability rapidly when a new requirement is inserted in a table. 

Linking the two specification documents as shown in the two left-hand columns has three main benefits. First, traceability is developed as the life cycle proceeds so that it is kept current — or nearly current. Second, there is a linkage between each URS requirement and the corresponding break down in the next document, allowing any changes to one document to be linked to the other one. Third, it provides a mechanism to check if all user requirements have been captured in the next document and is a simple mechanism for ensuring completeness of the following document. 

Traceability Matrix Combined with Functional Risk Assessment

Functional risk assessment (FRA) is a simpler risk analysis methodology that was developed specifically for the validation of commercially available software (5–7). This can be developed further into a traceability matrix. The process is as follows:  

The input to the process is a user requirements specification where each requirement is uniquely numbered and prioritized. All URS requirements are prioritized as either mandatory (M) or desirable (D). The mandatory assignment means that the requirement must be present for the system to operate; if "desirable" is assigned, then the requirement need not be present for operability of the system. This is shown in the first three columns of Table III.  

Table III: Functional risk assessment linked with a traceability matrix for commercial software			

The next stage in the process is to carry out a risk assessment of each function to determine if the function is business or regulatory risk critical (C) or not (N). This risk analysis methodology uses the tables from the URS that have two additional columns (columns 4 and 5) added to them, as shown in Table III. The approach is shown in the table in the fourth column from the left. Here, each requirement has been assessed as either critical or noncritical. For a requirement to be assessed as critical, one or both of the following criteria must be met. The requirement functionality poses a regulatory risk that must be managed. The basic question: will there be a regulatory citation if nothing is done? For example, requirements covering security and access control, data acquisition, data storage, calculation and transformation of data, use of electronic signatures, and integrity of data are areas that would come under the banner of critical regulatory risk (as well as good science). Requirements can also be critical for business reasons — for example, performance of the system or its availability.  

The FRA approach is based upon plotting the prioritized user requirements and regulatory or business criticality together to produce the Boston Grid shown in Figure 3. Requirements that are both mandatory and critical are the highest risk (combination of the prioritization and business–regulatory risk). For most commercial spectrometry systems, requirements fall into either the high- or the low-risk categories. There will be a few requirements in the mandatory and noncritical quadrant of the grid, but few, if any, in the desirable but critical quadrant. This is logical. If your requirement were only desirable, why would it be critical or vice versa? If requirements fall in this last quadrant, it might be an indication that the initial prioritization or the risk analysis was wrong, and either should be reassessed. Under the FRA, only the software requirements classified as "high" in the grid (mandatory and critical) will be considered further in the validation of a system. No other combination (that is, low) will be considered any further.  

Once the risk analysis has been completed, the advantage of the FRA approach is that a traceability matrix can be included in the same document. This is achieved by adding a fifth column to highlight where the requirement will be tested or verified in the remaining part of the validation. Some of the areas are illustrated in the legend to Table III and also are shown in the table itself. 

When we trace a requirement to the user acceptance testing or performance qualification phase of a life cycle, we have a number of options as to the depth of traceability that is possible. However, before we get into the detail, I'd just like to explain my terminology around PQ test documentation. The rationale is to help you to interpret and adapt this discussion to the names you use for this documentation within your organizations. Typically, when I conduct PQ testing, there is an overview of the testing documented in a test plan that links the test scripts that undertake the actual PQ testing.  

A test script contains the testing for a specific area of a system (for example, security and access control, audit trail, or library functions for identification of chemicals). We will use security and access control as an example of a test script for further discussion in this section. 

Each test script contains one or more test procedures that focus on a specific area within the focus area. So for our example of the security and access control test script, we could have test procedures for the correct password and user identity combination, access privileges for each user type, and account locking. 

Within each step procedure there are the individual test steps that will be used to test the functions and requirements of the system.  

In essence, there are four options to discuss and debate (shown in Figure 1). The answers will depend on how much time and resource you have at your disposal, but we must have a realistic level that is achievable and maintainable. The options: 

Trace 1: To the performance qualification phase as a whole and the requirements would be listed in the PQ test plan. 

Columns: Focus on Quality

The second part of this column series on traceability matrices looks at some of the practical ways of tracing requirements from the user requirements throughout the life cycle documents.

Validation of Spectrometry Software: The Proactive Use of a Traceability Matrix in Spectrometry Software Validation, Part II: Practice

Market Profile: Handheld and Portable FT-IR

The handheld and portable Fourier-transform infrared (FT-IR) market is a very new and rapidly growing market thanks to the intersection of technological advancements and new demand. Relative to other portable analytical technologies, the range of applications for the technology is more diverse. Despite the rapid growth and potential for this market, however, only a handful of competitors currently dominate the market.  

Handheld FT-IR demand by industry - 2008			

Like laboratory infrared spectroscopy, nearly all portable and handheld infrared instruments are now based upon FT-IR configurations. Technological improvements in areas such as optics and batteries have now reached the point of allowing for compact, portable FT-IR instruments that in some cases have the same performance as some benchtop laboratory instruments. 

Portable and handheld FT-IR instruments offer a combination of cost and performance that is not available in other portable analytical methods, such as mass spectrometry, ion mobility spectroscopy, and sensor arrays. In addition, FT-IR is capable of both liquid and gas phase analyses. Such advantages have made portable and handheld FT-IR popular among HazMat crews and other first responders, for in-field environmental analyses, for defense and security applications, and others. 

Smiths Detection has been the early leader in this market, but is now being challenged by the rapidly growing business of Ahura Scientific, which recently entered the market. The 2008 market for portable and handheld FT-IR was around $50 million and is forecast to break $90 million by 2013. 

The foregoing data were based upon SDi's market analysis and perspectives report entitled 

Global Assessment Report, 10th Edition: The Laboratory Life Science and Analytical Instrument Industry, September 2008

. For more information, contact Stuart Press, Vice President — Strategic Analysis, Strategic Directions International, Inc., 6242 Westchester Parkway, Suite 100, Los Angeles, CA 90045, (310) 641-4982, fax: (310) 641-8851, 

Departments

The handheld and portable Fourier-transform infrared (FT-IR) market is a very new and rapidly growing market thanks to the intersection of technological advancements and new demand. Relative to other portable analytical technologies, the range of applications for the technology is more diverse. Despite the rapid growth and potential for this market, however, only a handful of competitors currently dominate the market.

Spectroscopy-12-01-2008

Lenses

Validation of Spectrometry Software: The Proactive Use of a Traceability Matrix in Spectrometry Software Validation, Part II: Practice

Market Profile: Handheld and Portable FT-IR