All posts tagged: development

OpenIoT is a generic middleware platform for Internet-of-Things applications, which allows you to link together Internet-connected devices and semantic Web services via a friendly user interface, working either in Cloud Computing environments or with a local server.

This platform is available as a Virtual Development Kit, providing a complete cloud solution for the Internet of Things which allows you to easily get up and running getting information from sensor clouds and connecting this information with Web services without worrying about exactly what different sensors are being used.

The OpenIoT middleware enables the easy scalability of sensor networks and the addition of new, cost-effective sensors in an intrinsically flexible framework, and aims to provide a complete middleware for Internet-of-Things applications, connected sensors and wireless sensor networks.

OpenIoT is building a novel platform for IoT applications, funded by the European Union, which includes powerful capabilities such as the ability to compose (dynamically and on-demand) non-trivial IoT services using a cloud-based and utility-based paradigm.

With an aim to facilitate open access to a wide range of technologies for Internet-connected sensors and other objects exposed as “services”, the creators claim that OpenIOT is the first open-source project to provide the means for setting up, managing and using a sensor cloud in this way.

With the ability to support large-scale deployments by co-scheduling access from thousands of simultaneous users to millions of sensors and actuators, OpenIoT will be well placed for all IoT-based solutions of all sizes, and it will have a small number of its own open (public data) sensing services for anyone to send queries to.

The OpenIoT project explores efficient ways to use and manage cloud environments for IoT entities and resources, such as sensors, actuators and smart devices, and the management of utility-based, pay-as-you-go business models for IoT networks and services.

The platform will provide instantiations of cloud-based and utility-based IoT sensor and data management services, using the OpenIoT adaptive middleware framework for deploying and providing IoT services in cloud environments to enable the concept of “sensors as a service” business models for commercial IoT applications.

OpenIoT supports flexible configuration and deployment of algorithms for collecting and filtering the large volumes of data that are collected by networks of Internet-connected objects, and processing and detecting those events that are determined to be particularly interesting and relevant to application or business outcomes.

As OpenIoT is a completely open-source project, and all its source code is available for download – developers and end-users can examine and openly use the OpenIoT platform. You can use the OpenIoT source code to create innovative services, to extend OpenIoT with new sensor wrappers, or to improve the OpenIoT platform itself.

Furthermore, OpenIoT also aims to provide the capacity for semantically annotating sensor data, according to the W3C Semantic Sensor Networks specification, streaming the data collected from various sensors to a cloud computing infrastructure, dynamically discovering and querying sensors and their data, composing and delivering IoT services that comprise data from multiple sensors and visualising IoT data using many different options such as maps and graphs.

An example application area where OpenIoT has been targeted is the improvement of efficiency in industrial operations such as manufacturing and agriculture. The OpenIoT platform can be used for intelligent sensing in manufacturing environments where it offers rapid integration of data from sensors and other devices in the manufacturing environment, dynamic and intelligent discovery of new sensors in factories, and analysis of data collected from the factory floor.

The OpenIoT platform enables the dynamic selection of sensors along with the nearly-real-time fusion of sensor data in order to deliver any manufacturing indicators that are required – not just sets of inflexible, pre-configured indicators. This can increase the agility of decision-making and of the manufacturing process.

One example of this is an agricultural application – where farmers and researchers can benefit from an instantaneous crop performance analysis platform that is powered by OpenIoT, using a wide range of distributed remote sensors gathering various types of data in order to build models that predict crop yields.

Every year Australian grain breeders plant up to a million small test plots of wheat and barley across the country to find the best high-yielding varieties. The Phenonet application developed by OpenIoT in partnership with the CSIRO is an interesting demonstration of the capability of the OpenIoT platform, using advanced sensor network technology to gather environmental data from crop trials at a much higher resolution than traditional methods and providing an OpenIoT-powered high-performance, real-time online data analysis platform that allows scientists and farmers to visualise, process and extract both real-time and long-term crop performance information.

The Phenonet project enables plant breeders and farmers to compare and evaluate the performance of different grain varieties using real-time measurements from a variety of remote sensors. By combining these measurements with each plant’s genetic profile, plant scientists can distinguish the effects of microclimate and genetics, thus improving the accuracy and speed of plant breeding which leads to better crop quality and increased agricultural yields.

This is only one of an almost infinite number of applications that can be harnessed with the OpenIoT platform. And no matter what your requirements are, from concept to final product – here at the LX Group we have the experience and expertise to solve your IoT power problems right through to a whole system to meet your needs.

Getting started is easy – join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

LX is an award-winning electronics design company based in Sydney, Australia. LX services include full turnkey design, electronics, hardware, software and firmware design. LX specialises in embedded systems and wireless technologies design.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Moving away from a “waterfall” development process to a process that incorporates Agile methods, at least to some extent, can noticeably improve the quality and reduce schedules for the engineering of both hardware and software products.

However, in the case of a hardware-engineering task such as the physical design and layout of a complex printed circuit board or an ASIC we can’t simply release a half-complete iteration at any time and expect to get anything which is remotely functional or useful.

Although there are some important differences between hardware and software to consider when applying Agile methods, Agile is still valuable in the hardware domain.

When it comes to the layout of a printed circuit board, or the layout of an ASIC, this physical design iteration may take several weeks or even months to perform, to get from the netlist to working hardware. To get it right, several iterations may be required. Even when the time has been taken to complete this iteration, it may not make any sense, in terms of economics or customer value, to release this iteration to the customer.

Modular design and engineering is a valuable strategy for making Agile methods work in hardware development. Software developers have long understood this, using modular architectures such as object-oriented programming which limit the costly ripple effect of engineering changes in a tightly integrated system.

However, commercial electronic hardware designs tend to be highly integrated, not modular – since modular hardware systems tend to be more expensive. The cost of engineering changes, however, is higher in a more integrated system.

The use of modular components, FPGAs, pre-manufactured modules or development boards is particularly attractive during research and development for the rapid evaluation and prototyping of different circuits and component choices.

Although requirements for miniaturisation, cost, weight or reliability (e.g.. removal of connectors) may lead to a final, finished product that looks very different to the modular prototype version on the R&D lab bench, Agile techniques such as rapid iteration and the rapid delivery of new prototypes at the end of each sprint can be particularly relevant and useful during this stage of product design even though they may be somewhat less applicable later.

Agile hardware developers do not have any one solution for the question of modularity, since market forces tend to push us away from modularity. Increasing modularity typically increases the cost of hardware, as well as factors such as hardware size and weight which may be critical for some products, pushing us back towards increased integration and miniaturisation where the “cost of change” is higher.

Unlike software, hardware systems tend to have a much greater cost of change, and this means more time is required to recover the cost of each change. This tends to lengthen the optimal release rate for a hardware project incorporating Agile techniques, as compared to a software product.

Although many aspects of hardware product design, such as PCB layout, physical design of ASICs and tooling for plastic moulding are intrinsically time consuming and relatively expensive to iterate, many other aspects of hardware design such as electrical rule checking, ASIC verification, documentation, and the development of the firmware and software that is intrinsically associated with the hardware in most modern embedded devices are intrinsically more similar to the software development tasks that Agile methods were originally developed for.

Therefore, Agile methods lend themselves to these parts of the development of a hardware project very well, even if some other aspects of hardware development are not quite as well suited. The same is also true in the case of hardware logic that is implemented in an FPGA or CPLD – particularly during prototyping or R&D phases, where an FPGA may be used instead of bespoke ASIC hardware.

Depending on time and cost constraints for the project, it is also possible that an FPGA or other programmable logic device may be kept in the final production hardware, instead of an ASIC, which does provide a benefit in terms of agility.

The fact that it is generally not profitable to release new iterations of hardware products continuously to customers does not preclude us from taking advantage of Agile methods to develop our hardware products more continuously, in smaller batches, and to realise the Agile principle that the highest priority is to satisfy the customer early through continuous delivery of value.

Although this is often taken to mean continuous delivery of newly updated software or hardware products, continuous improvement in the value delivered to the customer doesn’t necessarily mean continuous expensive iterations in physical design, manufacturing and tooling for new hardware delivered to the customer – incremental improvements in customer value can be achieved using the previous iteration of physical hardware that is already in the hands of customers.

Therefore Agile project management techniques can be very useful and applicable to the design of hardware products – although the agile techniques that are employed and the way and time when they’re employed can be somewhat different to the application of Agile techniques in the software industry.

Here at the LX Group we can work with the development methods of all our current and future clients – and can put Agile development methods to work for your success.

Getting started is easy – join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

The Agile Manifesto is based around twelve principles, guiding concepts which build upon the four core values of Agile and support project teams in implementing Agile management methods, helping to lead to better project outcomes, better engineering and better customer satisfaction.

Let’s review these twelve principles of Agile project management and the relevance that they have to project management, particularly in the context of embedded computing, electronic engineering and product design projects.

The first principle is that it is the highest priority of an Agile project team to satisfy the customer through early and continuous delivery of valuable technology – and this remains true whether the product is software or hardware, embedded firmware, or any type of industrial design or engineering product.

Valuable engineering that is delivered to the customer early and continuously may not be the final product, but it might consist of rapid design iterations, demonstrations of certain subsystems or modules, proof-of-concept engineering, or prototypes constructed for demonstration using rapid manufacturing and rapid prototyping techniques such as 3D printing or digital logic synthesis in an FPGA.

The second of the core principles of Agile project management is that changing requirements should be welcomed, even late in development. This means that the customer should not be expected to provide a complete and concrete specification of all project requirements at the start of the project and never change or add to it.

Change should be welcomed, and Agile processes harness change for the customer’s competitive advantage. This principle applies equally for embedded design and hardware projects as it does for the management of software projects, however obviously there can be challenges when incorporating new requirements from the customer into a hardware project late in development.

For example, it may be difficult to incorporate new or different requirements into an existing PCB design and layout, requiring increased time and cost to design and fabricate a new PCB. In some cases, depending on size and mechanical requirements, using multiple modules and interconnected boards within a hardware system can allow for easier changes or the addition of new functionality without “wasting” existing hardware and its embodied time and money if a new iteration is required.

The use of programmable logic devices or FPGAs, or microcontrollers with their functionality reconfigurable in firmware, can also be useful in this regard – although this may increase cost or power consumption compared to a hardware system with application-specific, fixed functionality.

The third of the core principles of Agile management is to deliver working technology frequently, over a timescale of a couple of weeks to a couple of months, with a preference towards keeping this timescale as short as possible.

Like the other principles we have discussed, this principle is also useful and applicable towards hardware projects. Although there may be insurmountable time constraints, such as lead time for components, PCB manufacturing or assembly, the rapid delivery of working iterations of hardware, even if it is just for a subsystem or a prototype that validates part of the overall system design, is a valuable goal and it is practical to achieve in most cases in a typical hardware project.

Another of the twelve principles of Agile is that working engineering that can be demonstrated, even if it is just a subsystem, a component, an experiment or prototype and not the “final” deliverable product, is the primary measure of project progress. Other metrics that might be applied to gauge project progress are of secondary value compared to the actual technology created.

Further core principles of Agile are that business people and customer representatives should work together intimately with developers and engineers throughout the project, with close contact and communication between them during project development, preferably every day, and that project teams should be built around motivated individuals on the development or engineering teams who are given the support and environment that they need to get the job done, as well as given the trust that they will get the job done without micromanagement.

Among the other core principles of Agile project management are the principles that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation, and the belief that Agile processes promote sustainable development and a sustainable use of the human resources of the team, where the sponsors, developers, engineers and users making up a project team should be able to maintain a constant pace of work indefinitely.

The remaining principles are that continuous attention to technical excellence, good engineering and good design enhances agility, that simplicity and the art of maximising the amount of work that does not need to be done is essential, and that the best architectures, requirements and designs emerge from self-organising teams.

Finally, one of the core principles of Agile management is that it values regular adaptation to changing circumstances. Ideally, an agile team reflects on how to become more effective and then tunes and adjusts its behaviour accordingly at regular intervals.

These Agile principles also retain their advantages and their potential usefulness irrespective of the technical nature of the particular project that you’re managing – there is no real difference between a software project or a project working with electronic hardware or any other kind of engineering or non-engineering project when it comes to understanding the potential benefits of these Agile values.

With some thought and buy-in by all members of your team, you can use Agile methods on a wide variety of projects. And if you’re looking for a partner in yoru project development, here at the LX Group we have the team, knowledge and experience to bring your ideas to life.

Getting started is easy – join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Agile project management methods aren’t new, however they can still be considered somewhat foreign to most teams developing hardware or combined embedded hardware and software products.

There are a number of both advantages and potential disadvantages that are worth considering when it comes to the role of Agile management methods in hardware projects that should be considered in the decision-making process of switching from a traditional waterfall project management method to an Agile approach for the management of your projects.

Imagine a team that focuses on how their work will be used by the customer, and who quickly incorporates feedback from other teams and test users to build something that gets better and better in noticeable and usable incremental chunks of productivity. They may work without the usual documentation and strict procedures because communication is fast and usually face-to-face, with the results being what is important.

These are some of the typical advantages associated with Agile project management techniques, along with improvements in efficiency and team productivity that come from co-location of teams, pair programming (and more generally, “pair engineering” in the context of a non-software project), regular stand-up meetings and similar interpersonal communication techniques within your project team that are an important part of many Agile methods.

Some of the other key advantages that are typically ascribed to Agile project management techniques include the reduction of traditional, formal written documentation because of the sense that reducing the requirement for this type of documentation allows creativity to increase, a reduction in the time that is typically consumed doing blind research, and the relatively rapid delivery of new iterations of hardware or software prototypes which allow improvements to be demonstrated more rapidly, broken up into smaller chunks.

Another advantage of Agile methods is that multiple cycles of iterative development, testing and feedback speed up the evolution of a quality product, as well as allowing relatively rapid education of new members of the development team, allowing skills and experience with particular tools, client industries or user stories to be learned rapidly where prior experience may be lacking.

Despite many apparently compelling advantages of Agile methods, however, some development teams and companies prefer the perceived stability and predictability of a traditional development process and a “waterfall” project model.

They feel that the traditional approach of comprehensive documentation and specific up-front contract negotiation protects them from risk and allows one team to follow the work of another in a consistent and reproducible way. When your product involves a combination of hardware and software – as is often the case in today’s world of embedded systems and connected Internet-of-Things devices, this involves special hurdles and some people feel that agile methods are not well suited, or insufficiently well developed, to handle this area well and that traditional engineering management strategies are the best when you’re working with this type of technology.

Some possible disadvantages that you may encounter when trying to incorporate agile methods into your product development include an increase in the amount of data that you need to manage, in order to keep track of rapid revisions and many different versions of prototype hardware and software, and the increased complexity of your communication and coordination within your team and between the team and the customer as the project proceeds.

Some organisations may find that they have a hard time getting over the disadvantages of changing their processes and dealing with perceived increases in risk. There are real costs associated with your transition to new, different procedures and tools, and the perception that moving away from formal up-front contract and specification processes with your clients could expose you to increased risks can be, to some extent, correct.

Another one of the challenges facing agile management of projects with both hardware and software development components is that software can normally be developed relatively rapidly, and the software development process broken down into smaller chunks or iterations relatively easily.

On the other hand, it may require three to six months or more to develop an iteration of a hardware product and to demonstrate a working component or feature. Hardware is hard, as they say, and it is harder to break up the project into small components that can be worked on in small, short sprints with a working iteration of a product or component at the end. If the software must wait for the hardware to be created prior to final testing of the integrated system, this can add delays to your testing process.

Nevertheless, don’t let these put you off considering Agile for your project development. By working with experienced partners you can exceed your goals, and here at the LX Group we have the team, knowledge and experience to bring your ideas to life.

Getting started is easy – join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Agile project management practices, which can be applied to the management of hardware development or other engineering projects – and not just the software development projects for which these methods were mostly originally developed, have the potential to deliver increased customer satisfaction compared to traditional project management methods such as the “waterfall” technique.

These improvements in customer satisfaction that can be achieved by Agile projects come about because of a combination of many different advantages that Agile practices can offer, particularly in the ways that Agile project techniques involve and engage the customer, the customer’s feedback, ideas and expertise throughout the product development lifecycle.

These Agile project management practices can increase the satisfaction of your customers by keeping the customers involved and actively engaged through the development cycle of their new product, making the customer feel like they are a valuable, integral part of the project team – which, of course, they are.

This enables rapid and precise feedback between the customer (or customer representatives and advocates on the team such as the “Product Owner”, who often play an important role in Agile project teams) and the development team.

Furthermore this also gives the development team an intimate contextual understanding of the customer’s requirements, specifications and ideas by keeping the customer or customer champion embedded in close contact with the development team. Finally, customer satisfaction is increased thanks to your progress and with the product; these practices can help to make the product itself fundamentally better, too.

Whilst these kinds of Agile project methodologies can work at their best when an actual customer representative is available frequently for team meetings, to communicate product requirements and business needs, if a customer representative is not available then the Product Owner, a role filled by one member from the project management team, can perform this role effectively.

The “Product Owner”, who is a core part of many Agile project teams, is an expert on the customer’s needs and product requirements, and serves as an advocate for customer and business outcomes, constantly directing the team in a direction that is focused on customer results and customer centred value, rather than considerations such as what is technically easiest, or technically most elegant, which otherwise may be given greater emphasis by the engineering or development teams.

Agile project management practices can deliver improved customer satisfaction and customer-focused outcomes by keeping the product backlog updated regularly and prioritised, allowing the team to quickly and efficiently respond to urgent issues, to newly established product requirements, or other changes that need to be addressed, without wasting time with less organised project management or implementing new features or changes that are less urgent and less important to the customer and business outcomes. Agile practices can also deliver improvements in customer satisfaction and product outcomes by demonstrating working functionality to customers in every sprint review.

This rapid iteration of new prototypes and repeated demonstration of working software or hardware technology gives the customer and/or the Product Owner a very clear understanding of the project progress that is being made, inspires new ideas for features or changes either in the product itself or in the ways that the product may be used or marketed, and allows for rapid discussion of changes, improvements or design specifications that are desired between the customer and the project team.

Another way that Agile management practices can result in a project with relatively strong satisfaction for the customer is by delivering products to market quicker and more often with every release.

Finally, another factor that can allow Agile project management techniques to deliver greater customer satisfaction from your project is by possessing the potential for better results with self-funded or crowd funded projects; allowing the scope, scale or schedule of a project to rapidly be changed even in the middle of the project development cycle.

This means, for example, that Agile projects can adapt to be most compatible with a changing or insecure funding environment, a self-funded environment with very limited access to cash flow and resources, a crowd funding project that has delivered funding less than what has been hoped, or a crowd funding project that has turned out much more successful than anticipated, with plenty of upfront funding available, but with demands for manufacturing scale and product fulfilment that are much larger than originally anticipated.

These and other Agile hardware development techniques can be harnessed by any organisation. However if this is new to you, or it seems like a complex path – then consult the experienced team here at the LX Group.

We can partner with you – finding synergy with your ideas and our experience to create final products that exceed your expectations.

To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

In the adoption of Agile project management practices to the development of hardware or combined hardware-software engineering projects, and the adaptations to common Agile techniques that may be applied for best results with hardware projects, let’s consider some of the challenges that may be faced and how you might address them.

For example, do you develop software and firmware only after you’ve developed and assembled an iteration of physical prototype hardware? Or do you develop an iteration of your software and firmware concurrently with the development and assembly of the corresponding hardware and use other methods such as simulation to stand in for the hardware until an iteration of the physical hardware is ready?

When using Agile project management techniques, it is desirable to be able to rapidly produce and demonstrate a working prototype of your technology and to rapidly iterate and refine and build on each prototype without necessarily having a perfectly engineered product ready to go at the first iteration. When you’re working with hardware, however, you need to deal with the lead time required to source components, to fabricate printed circuit boards, to have prototype layouts assembled by an external pick-and-place assembly contractor or to have custom plastics injection-moulded and so on.

What if the lead-time required for these processes is longer than the time allocated to a particular iteration or sprint? These types of external supply and manufacturing dependencies are unique to hardware, and aren’t present in software development – so they present a unique challenge when trying to apply agile methods to the management of hardware projects. While these constraints may seem like a daunting challenge to adoption of Agile in the hardware engineering industry, techniques and tools such as in-house rapid prototyping, 3D printing, CNC milling of simple PCBs and the like present part of a potential solution, allowing for rapid, agile iteration of hardware prototypes.

A prototype iteration of a hardware system doesn’t have to physically involve hardware, either. Simulation and visualisation tools can play a valuable role of validating the design and performance of all the components that come together into a new product, even before a prototype is actually physically constructed. FPGAs and logic synthesis may also be valuable tools here, allowing for validation of soft cores before physical hardware is constructed. One of the challenges for combined software and hardware development is that software can normally be developed fairly rapidly and the development broken down into smaller iterative chunks. Hardware, on the other hand, may require months to show a working component or feature, which has been implemented starting from scratch.

If the software development must wait for the hardware to be created before final testing, this can create significant testing delays. Hardware must also often follow strictly defined process models, meet compliance standards, and it can be difficult to make late changes to hardware. This means that feature creep can be difficult and expensive in hardware engineering, although Agile methods are traditionally more accepting of “feature creep” compared to traditional “waterfall” management methods.

Traditionally, the priority for embedded software, for example, would be to write the hardware drivers first, to allow evaluation of the new device and to allow testing. Testing is more complex when software must fit within a small, cheap microcontroller with limited resources in an embedded system, with timing well controlled to prevent race conditions and other timing issues. This means that at some point testing on the actual hardware is generally important. A problem often seen when businesses who create hardware and the software that runs it face when trying to “go Agile” is that they attempt to take methods and practices developed for software (such as Scrum, an Agile project management framework), and try to use it for everything, including hardware development.

Scrum is based upon “sprints” of relatively short lengths (two weeks to 30 days), with highly defined tasks that must be completed during the sprint. The nature of software development makes this an excellent framework for rapid progress; but scrum isn’t necessarily the best framework for hardware development. If the products are in a highly regulated industry, such as medical or aviation hardware, then the documentation must follow industry requirements for specification and design, as well as normal testing and functional requirements documentation. This makes it extremely difficult to use scrum by itself, since the processes for hardware are frequently much more rigid, defined, and design-oriented than those normally defined by scrum.

On the software side, because software must interface, communicate with, and control hardware, development issues using Agile are more complex for combined software/hardware projects, and the stories (definition of the functions for a specific feature) that the developers define for each sprint are accordingly more complex. Large projects with large amounts of hardware and software dependencies can be even more challenging.

One method of dealing with hardware that isn’t ready to test is to decouple software and hardware development, via an abstraction layer, to allow software development to continue more rapidly. Can the interfaces to the hardware module be specified, and the specifics abstracted away to allow other parts of the hardware and software development to continue around the hardware component that is behind schedule? The challenge is to find a method that allows the rapid development of software with concurrent development of the hardware, that can best meet the requirements of each process. A good approach can be the use of different Agile techniques for hardware projects than those used in software projects. Agile techniques are not abandoned – simply implemented a little differently, with different specific Agile techniques chosen for the most effective results.

With Commitment-Based Project Management (CBPM), which has been described as an “agile without using Agile” technique with broad applicability outside the software engineering sector, the emphasis is on the delivery of at least a component or piece of the hardware that works, in the case of an embedded computing or other combined hardware-software project, in order to allow the development or testing of the software that will work on that hardware component. This is very different from the traditional “waterfall” project management approach, where the entire hardware system needs to be built first. While the “scrum” method for software projects is based on sprints with small portions of the software completed at a time, hardware development can benefit from a different approach.

With Agile, both hardware and software features are broken down into smaller chunks – only the Agile methodology can be a bit different for each. Once software is working, it can be deployed either on any available hardware modules that are ready, or in a test or simulation environment. This allows the early identification and fixing of race issues and bugs that arise, and reduces the amount of “fixing” and lengthy hours reworking that must occur during late integration and testing when the hardware is ready.

And that’s the goal of successful agile development – to reduce the total time required, decreasing errors, mistakes and the chances of unforseen events, which will increase the time to market for your new or revised product. Here at the LX Group you can leverage our product development expertise and experience for your total benefit. Our consultants, engineers and experts in many fields can guide you to your goal of product success. To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

When using Agile project management techniques, it is desirable to be able to rapidly produce and demonstrate a working prototype of your technology, and to rapidly iterate and refine and build on each prototype without necessarily having a perfectly engineered product ready to go at the first iteration.

When attempting to apply Agile methods to electronic and hardware design, what methodologies and tools should we consider in order to rapidly prototype and demonstrate hardware systems?

What if the lead time that is required to source components, to fabricate PCBs, to have prototype layouts assembled by an external pick-and-place assembly contractor or to have custom plastics injection-moulded, and so on, is longer than the time allocated to an iteration? These types of external supply and manufacturing dependencies are unique to hardware, and aren’t present in software development – so they present a unique challenge when trying to apply agile methods to the management of hardware projects.

Increasingly popular and accessible tools and technologies such as small-scale CNC milling, 3D printing, and laser cutting are becoming more important in this field, allowing components such as custom plastics to be rapidly prototyped, rapidly demonstrated to the product owner, evaluated, and rapidly iterated, prior to committing to the high cost and high lead time of custom injection-moulding tooling and manufacturing.

In agile methodology, early user testing is important, with rapid feedback focussing the most important characteristics of a product and showing what is or isn’t relevant for customers. To shorten the time required to deliver a prototype iteration, rapid prototyping tools and technologies such as 3D printing are ideal, bringing rapid, small-scale and very agile manufacturing technologies right to the desktop.

Having intimate, agile communication between different team members with different skills – electronic engineers, mechanical engineers, industrial designers, UI designers, software developers, manufacturing experts – with regular meetings, standups and interaction is also good for efficiency and agility, allowing cross-pollination of different experience and ideas and providing confidence in the integration between different parts – between a plastic moulding and a printed circuit board, for example – preventing time-consuming problems with manufacturability later.

If you’re working on a hardware prototype in an agile environment and your external manufacturing of a new prototype board, for example, is going to take longer than the time allocated to an iteration but you need a prototype ready to demonstrate, what options are available to you?

Then it is time to ask if there is anything that you can do so that you can produce a prototype of some kind in an iteration, using the new tools and technologies of rapid prototyping – or even the older technologies of hand construction. Today there are services that can allow you to upload design files for a new 3D printed plastic part or CNC machined metal part and have it manufactured and shipped overnight so that it is ready to go the next morning. These services can be expensive – but so is the time of your team, and the agility that such rapid iteration provides could be more valuable.

A prototype iteration of a hardware system doesn’t have to physically involve hardware, either. Simulation and visualisation tools, such as SPICE for electronic engineering, 3D rendering of PCB component dimensions, 3D rendering of mechanical components, and thermodynamics models for predicting heat transport with a device enclosure, for example, can all play an important role in assuring the quality, interoperability, industrial design, electrical and thermal performance and the “look and feel” of all the components that come together into a new product – even before a prototype is actually physically constructed.

Nevertheless some of the most rapid of rapid prototyping strategies can fail, so is there a different way to somehow produce something at each iteration that can generate the discussion, answers and feedback you can use to drive decision-making within a single iteration?

What are the basic, smallest chunks of hardware functionality that you can deliver? Can you split the hardware prototype up into small modules, for optimum agility and the ability to deliver a prototype of at least one module during each iteration period?

Using standard off-the-shelf components and technology for rapid prototyping can play a valuable role here, along with breadboard-style construction, the use of manufacturer evaluation boards and reference-design boards from chipset and IC manufacturers, the use of general-purpose “building blocks” and “breakout boards” from component distributors, and general-purpose single-board computer and microcontroller modules, which are relatively low cost, flexible, and very easy to learn to use.

The use of Open Hardware and open-source intellectual property, for example for known working circuit designs that can be re-used without having to spend your time reinventing the wheel, is also potentially attractive here.

Today, almost all electronic products and designs incorporate some kind of software or firmware – for an embedded microcontroller, for Internet-connected cloud services or mobile apps or for PC connectivity, for example. This is especially true as we move further into the emerging Internet-of-Things era.

This means there is a relationship between electronic engineering and software engineering for almost all products, and agile methods can help to make this interaction most efficient. Once software is working, it can be deployed either on any available hardware modules that are ready, or in a test or simulation environment. This allows the early identification and fixing of most race-condition issues or bugs that may arise, and reduces the amount of “fixing” and time intensive reworking that otherwise might need to occur later into the integration process.

The goal is efficient, concurrent work with hardware developers creating hardware components, and software developers developing and testing software components, at first independently of the hardware development at times, and then testing on the actual hardware prototypes as they are developed. This requires effective collaboration between hardware engineers, industrial designers, software developers, and the product owners who provide the feedback.

No matter the level of expertise within your organisaiton – you may need help or guidance with any or all stages of product development. Here at the LX Group we have a wide range of experience in various development methodologies and can be your partner for success.

To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

LX is an award-winning electronics design company based in Sydney, Australia. LX services include full turnkey design, electronics, hardware, software and firmware design. LX specialises in embedded systems and wireless technologies design.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

A concept that may be new to the reader – Agile software development – is a family of software development methods based on iterative and incremental development, in which requirements and solutions evolve through collaboration between self-organising, cross-functional teams.

It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen tight iterations throughout the development cycle. Over the last 15 years or so, the principles, practices, methods and tools of the Agile movement have significantly changed the landscape of the modern software engineering and development industry.

Compared to traditional engineering project management approaches, agile development is mainly targeted at complex systems and projects with dynamic, non-deterministic and non-linear characteristics, where accurate estimates, stable plans and predictions are often hard to establish in early stages, and complex up-front designs and prototypes are not likely to be practical or economical.

These basic principles and precious software industry experience from years of successes and failures have helped shape Agile’s favour of adaptive, iterative and evolutionary development.

However, hardware developers and engineers tend to see software development as something of a foreign land, with strange people, languages, tools and processes. Agile development processes may seem odd or unusual, even though they are becoming more mainstream in software development. While software developers have largely accepted the merits of agile development in many project environments, there is little adoption of agile principles in hardware design and electronic engineering circles.

So, are there any potential benefits to the adoption of agile development methods in hardware engineering? Might the values and principles that guide agile software teams similarly guide hardware engineering teams, or are the differences between hardware and software development too great?

Since Agile practices are relatively unknown in the hardware industry, it can be difficult for the average hardware developer to offer an informed opinion on agile. Complicating matters is the fact that an accurate and tangible definition of agile can be difficult to pin down. Even in software circles where it has been used for years, agile can have different meanings, bring varying degrees of success and bring with it different baggage compared to the traditional methodologies of software development and project management.

Fortunately, hardware developers are usually in a position to develop a “fresh” consideration of agile practices and the benefits that they may have for their work, avoiding the opinions or misconceptions that others may have established about agile methods.

We can begin by considering the core high-level principles of the “manifesto” of agile development and the established practices that have contributed to the success of agile methods in the software development industry for many years.

The Agile Manifesto was conceived as a launchpad from which the developers who first formalised the concept of agile development processes could reverse and change course away from what they considered to be the “damage” that was being done to the software development industry by traditional project management techniques such as the waterfall development model.

The pioneers of agile believed that the top-down, process-centric, heavily formally documented and painfully deliberate style of project management that many organisations followed was proving less and less successful. The underlying premise of the traditional “waterfall” project model is that the design and engineering of some product can be defined in advance through the construction of a detailed project plan, and that development then becomes a largely mechanical process of staged execution according to the plan.

According to agile practitioners, however, a fundamental flaw in applying the waterfall model to the management of many real engineering projects is that the act of designing and constructing software or hardware cannot be completely, reliably defined in advance. Software development, they argue, is a creative process and due to its inherent uncertainty cannot be accurately planned entirely in advance.

Product vision, customer need, target market, target technology and team dynamics, among other things, can vary considerably and unpredictably during development. For a creative process like software development, therefore, it is agility and adaptability that drives success rates to a greater degree than the intense upfront planning that is characteristic of waterfall development.

But is hardware development a creative or defined process? Before jumping into an analysis of the applicability of agile methods in hardware development, it is important to first categorise hardware development as either a creative or a defined process. Presumably, hardware development viewed as a somewhat creative process would benefit through the application of agile development methods in the same way as creative software development.

If, on the other hand, one decides hardware development can truly be captured as a defined, mechanical process in an accurate and reliable project plan, then you might argue that the problems agile methods are designed to address do not exist.

Or if it is not honestly possible to build a detailed project plan that accurately captures a complete development cycle prior to product development, if detailed project plans do not remain completely stable over time, if it is not possible to build a concise set of project requirements that will satisfy customer and market requirements years into the future, or if target technologies and architectures are not going to remain stable, thoroughly understood and unlikely to change into the future, then it is clear that a strictly mathematical, rigid process of project management will not be completely effective, and the benefits of agile development methods are potentially quite applicable to your project’s success just like they are in the software industry.

Development, of hardware and software, is carried out by people complemented by process and tools, not the other way around. Agile proponents believe that businesses erroneously link success to efficiency brought by process and tools as opposed to the innovation and creativity brought by people and teams, and agile encourages organisations to see people and communication as the critical factors in building great teams and great technology, with process and tools being complimentary.

Emphasis on individuals and interactions over processes and tools, rapid delivery of working prototypes and iterations even if they are not perfectly polished and complete, active customer collaboration and responsiveness to change are some of the core values embodied in agile practices, with formal contract negotiation, strict plan-following, and comprehensive documentation in the traditional written sense being de-emphasised if these practices are not the most effective way to understand customer requirements and for the team to understand and support each other’s engineering and project progress.

However, some of these concepts may be new for hardware engineers, since traditional waterfall-model values such as tools, process definition, comprehensive documentation, the hammering out of requirements during initial contract negotiation, the avoidance of feature-creep and the avoidance of change to initially negotiated customer requirements, are traditionally preferred and relied upon in hardware development.

One key philosophy of agile development is that face-to-face conversation and co-location enable the best communication between engineers, developers and customers. and a common practice in agile development is the daily “stand-up” status meeting where team members briefly report to each other what they did the previous day, what they intend to do today, and what their roadblocks are. Whilst there are many specific agile development methods in practice, most consistently promote teamwork, collaboration and process adaptability throughout the project lifecycle.

Agile methods emphasise the creation of working technology, i.e.. a hardware or software prototype, or iteration that can be demonstrated, as rapidly as possible, then demonstrating it and incrementally adding features throughout development. Working technology gives the team, stakeholders and customers regular opportunities to objectively measure progress and offer feedback based on a working prototype product, even if all its functionality is not completely implemented in a form ready for product release, and presenting real technology is likely to be more useful and welcome in a client meeting than just a presentation of documents or slideshows.

Furthermore Agile also encourages regular customer collaboration as the only practical way to gain and maintain a clear understanding of customer value as it inevitably evolves over time. Products are designed to satisfy customer needs, so it is customers that are best equipped to lead development, and agile practices favour close, daily cooperation between business people, customer representatives and engineers.

For many, responsiveness to change is the core value of an agile team, since technical development is a creative process where it is impossible to predict, understand and plan with pinpoint accuracy over an extended period of time. Often, long-range planning becomes a futile attempt to gain confidence and control over the development process. Agile project managers argue that absolute confidence and complete control are impossible to achieve, and customer needs, requirements, team dynamics and project goals will change over time, making long-range plans obsolete. Agile teams pride themselves on successfully absorbing change by combining detailed short-term planning with long-range estimates.

Iterative development, where products are built and demonstrated over a number of regular intervals, is the primary means by which agile teams realise the value of working technology. Hardware demonstrated through simulation, virtual models, prototypes or emulation platforms can be used to demonstrate products, quantify progress and gather feedback.

hile iterative and test-driven development are potentially disruptive for hardware developers, the benefits of objectively viewing progress with tested, working technology are hard to ignore. This is especially true early in development when the value of documentation and untested engineering can be difficult to quantify. Iterative development and regular technology demonstrations are also an effective way to keep customers or customer advocates involved, thereby ensuring progress is indeed progress in the right direction to meet customer needs.

In a step further, some agile teams embed their customer within the actual development team so that they are available at all times for questions and clarifications. For some, embedding a customer within a hardware development team would undoubtedly be controversial. But regardless of the perceived problems, increased collaboration and transparency with the customer is a reliable way to secure trust and ongoing success in the vendor-customer partnership.

Hardware development in itself can be minefield for those without the experience and resources to get the job done on time to specifications and on budget. However by partnering with the LX Group we can work together to offer solutions to your problems.

To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

LX is an award-winning electronics design company based in Sydney, Australia. LX services include full turnkey design, electronics, hardware, software and firmware design. LX specialises in embedded systems and wireless technologies design.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Device Cloud by Etherios is a device management platform and data service that allows you to connect a huge range of devices to Internet-connected applications, anywhere. As a public cloud service, it is designed to provide easy integration between devices and the cloud, facilitating real-time network management and rapid development of machine-to-machine and Internet-of-Things applications.

Using Etherios Cloud Connector and the open-source APIs available it is easy to integrate a wide range of client software, including web applications or mobile applications, with Device Cloud.

This public cloud platform provides easy cloud-based management of device networks, secure application messaging and data storage for Internet-of-Things and machine-to-machine networks comprised of wired, wireless networked, cellular and satellite-connected devices. It offers customers centralised management of gateways and connected end-devices, ease of integration via APIs and Etherios’ Cloud Connector, elastic scalability of the cloud platform, allowing easy and cost-effective growth as your device network grows, enterprise-level reliability and industry-leading attention to security.

To get started trying out Device Cloud, you can simply create a free Device Cloud account and enjoy access to Device Cloud services including Device Manager with up to five devices and support for Web services, data streams and SMS connectivity. With a free Developer Edition account you’ll have access to all the features of Device Cloud in order to design, test and prototype your Internet-of-Things or machine-to-machine solution, and you’ll be able to freely evaluate all the functionality and features of Device Cloud for a small network of devices.

There are two Device Cloud hosting centres at present, one in the US and one in Europe. When creating a Device Cloud account you can select which hosting centre to use, allowing latency to be minimised by selecting the hosting location that is geographically closest to the majority of your devices that you will be registering to Device Cloud.

Traditionally, devices were expected to keep a persistent network connection open to Device Cloud, with an occasional keep-alive or heartbeat signal sent to confirm the link while application data was not actively being sent. However, Device Cloud now incorporates SMS support for deployment scenarios where bandwidth costs are high, allowing some actions such as a device reboot to be initiated remotely via SMS.

For more complicated communications, Device Cloud can send an SMS “shoulder tap” to request a connection, causing the device to initiate a traditional connection back to the server over the cellular link only when such a connection is really needed, reducing bandwidth costs. Once connected, web services, requests and UI actions can connect to the device.

Connecting your products into the enterprise network can create new revenue streams, service offerings, and improved customer satisfaction. Etherios Cloud Connector is a software development package that helps to realise these goals by enabling you to securely connect essentially any devices in a machine-to-machine or Internet-of-Things network to the Etherios Device Cloud system. Supported devices range from Arduino boards, Microchip PIC and STM microcontrollers to Freescale and Intel chips, the Raspberry Pi single-board computer and common smartphones. Cloud Connector simplifies integration of your devices with applications and gives you easy, direct access to the data from your devices.

Etherios can help you to build a specific Device Cloud Solution that suits your needs, providing a free Dia framework including reusable software modules and open-source reference code, a free integrated development environment based on the Eclipse IDE that includes helpful examples and tutorials, and other sources of design assistance, including custom application development services. Etherios also offers expertise and services in embedded design, software services, electronic and RF engineering, and printed circuit board layout.

Etherios Cloud Connector is available for Android, Kinetis microcontroller devices and other common embedded platforms, allowing easy connectivity of many different devices to Device Cloud. The large family of “connectors” available simplify the process of managing dynamic hardware and device infrastructure, making it easy to deploy and modify your networks of connected devices and applications.

Highly elastic cloud infrastructure makes it easy to maintain a cloud platform that meets the needs of your expanding network – a complete, scalable, Internet-of-Things toolkit that is cost-effective at any scale.

A pre-built, cloud-based solution can offer fully featured, production-grade capabilities for an initial pilot and proof-of-concept of your Internet-of-Things service or product, and Device Cloud enables application developers to bring a product to market very quickly and easily compared to bespoke solutions.

You could perhaps build your own platform, but only with significant investments in development time and cost in order to achieve the same range of features and functionality that is available from an off-the-shelf solution such as Device Cloud today. The primary benefit of Device Cloud is cost, with world-class scalability, reliability and security offered at an extremely competitive cost.

And with our team here at the LX group, it’s simple to get prototypes of IoT systems up and running – which also translates to lowering the cost of the system development through to the final product. We can partner with you – finding synergy with your ideas and our experience to create final products that exceed your expectations.

To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

With more and more embedded computing capability, networking and Internet connectivity inside everyday systems such as household appliances, security systems, home heating and lighting systems and even cars, information security has become a potentially important consideration in devices where it wouldn’t previously be considered important – potential security threats may be lurking in embedded systems in a growing number of everyday devices.

Nowadays it isn’t just familiar personal computers that are connected to the Internet – embedded computers are more ubiquitous and are also increasingly connected, and with that connectivity and computational power comes new security threats hiding in new places.

Internet-of-Things networks, smart home automation and persuasive connectivity and embedded computing bring with them exciting new opportunities – a connected home can allow you to log in to your home network before you leave work in the evening to turn on your central heating and your oven, or allow you to log in to your home security system from your smart phone in response to an alarm notification, check your security cameras and reset your alarm if there isn’t a problem.

Unfortunately, these new opportunities do potentially bring with them a new set of security threats. Whilst most consumers are now aware that their personal computers and smart phones are potentially vulnerable to malicious software or network attack, few are aware of the potential threat to other electronic devices.

The Internet of Things may be in its infancy, but threats already exist. For example, computer worms are known to exist that are designed to target embedded devices such as cable and DSL modems and other low-power embedded devices based on architectures such as ARM and MIPS – platforms that are associated not with personal computers, but with the Internet of Things and embedded devices such as modems, routers, industrial control systems and set-top boxes.

Malware exists that adds infected modems and routers to botnets that can be used to support attacks, such as distributed denial of service attacks, on other networks and systems.

What is particularly worrisome about these kinds of threat is that in many instances, the consumer may have no idea that these types of embedded computers are vulnerable to this kind of malicious attack. Devices such as modems or routers may “hide in plain sight” containing malware, and spread it back to personal computers on the same local network.

Once these PCs have been disinfected – or being “trusted” to remain online all the time, directly connected to the Internet in many cases, without being disconnected or decoupled from the Internet as other computers may be to prevent malicious attack or infection in a security-conscious environment.

Many users may think about hardware upgrades to devices such as network routers rarely, if ever, and they may never bother with firmware upgrades and patches – or even with ever changing passwords and login details for configuration of these devices away from their default settings.

In one prominent incident, Trendnet, an organisation that markets Internet-enabled security cameras and baby monitors, shipped some of their cameras with faulty software that left them open to online viewing, and in some cases listening, by anyone on the Internet who was able to discover a camera’s IP address.

The private camera feeds of hundreds of consumers were made public on the Internet. When this vulnerability became public, people published links to the live feeds of hundreds of the cameras, displaying children sleeping and people going about their daily lives. But these devices were not infected with any malware – they were simply designed and sold with negligible security measures in place, relying only on “security through obscurity” and allowing anyone to simply access them if they knew how.

Within the last few years, we have seen a huge range of new Internet-connected and networked embedded devices emerge, from household thermostats to light bulbs to TVs to cars. Although the Internet of Things is still immature, the number of Internet-enabled devices is beginning to explode. According to Cisco Systems, there are more than 10 billion connected devices on the planet – more devices than there are people – and they predict that the world will reach a population of 50 billion connected devices by 2020.

This huge population of connected devices obviously brings with it an increased potential for security vulnerabilities, and an increased need for security awareness, both by consumers and by device manufacturers. Consumers should be aware that just because an electronic device doesn’t possess a display or a keyboard, that doesn’t mean it is not potentially vulnerable to attack. All devices that are connected to the Internet – via Ethernet or Wi-Fi, and perhaps even indirectly – via Bluetooth or 802.15.4 wireless networks, looking into the future – need to be secured.

Consumers should pay attention to the security settings on any device they purchase, and disable capabilities such as remote access if they aren’t needed. Default passwords should be changed to unique, strong passwords that don’t use common, easily guessable numbers or dictionary words.

Furthermore end users should also regularly check manufacturer’s websites to see if there are any updates to software for their devices, since manufacturers will often patch security vulnerabilities with software updates if they are identified. And since network routers and modems are essentially the gateway between the Internet and other devices on the network, keeping these up-to-date and secure is very important.

However almost all security threats and possible incidents can be neutralised before the product reaches the end user. By designing appropriate levels of security into products – including various fail-safes such as mandatory passwords, firmware updates and better documentation and user education, a safer and more reliable IoT can be possible.

If you have a new product idea or an existing version that needs updating, we can take care of all facets of design and prodiucting – including the right security and user-interface to negate as much risk as possible.

To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.