Engineering Software Practice, Ethics, and Emerging Technologies

Introduction

Electrical engineers increasingly design systems whose behaviour depends on software: embedded controllers, power-system monitoring platforms, industrial automation, medical instruments, communication networks, and cloud-connected products. Technical success therefore requires more than writing code that appears to work. Engineers must transform requirements into an architecture, estimate effort, control changes, verify quality, protect information, respect licences, and make decisions that are safe, lawful, and ethically defensible.

This chapter presents an integrated engineering-software practice. It treats software as part of a socio-technical system: a system involving hardware, people, organisations, data, regulations, and operational environments. It also examines artificial intelligence (AI)-assisted coding, data analytics, machine learning, edge and cloud computing, and digital twins. These technologies can improve engineering productivity, but they introduce limitations involving reliability, explainability, cybersecurity, privacy, bias, cost, and accountability.

Learning objectives

By the end of this chapter, a student should be able to:

1. Convert stakeholder needs into testable requirements and a defensible software architecture.
2. Estimate effort, schedule, and risk using transparent assumptions.
3. Apply version control, code review, automated testing, and continuous integration (CI).
4. Analyse software security, privacy, licensing, professional ethics, and governance.
5. Evaluate AI-assisted development, analytics, machine learning, edge/cloud systems, and digital twins.
6. Participate effectively in a team-based engineering project and justify technical decisions.

1. From engineering need to software system

A requirement is a verifiable statement about a needed capability, constraint, or quality. A stakeholder need such as “the controller must respond quickly” is not yet a good software requirement. It should be refined into a statement such as: “For an input sampled at 1 kHz, the controller shall produce the protective output within 2 ms under the specified processor and communication load.” The refined requirement identifies an observable condition, a limit, and a context.

1.1 Requirements classification

Functional requirements describe what the system does: measure voltage, calculate state of charge, record an alarm, or command a relay. Non-functional requirements describe qualities or constraints: latency, availability, maintainability, safety, energy consumption, accessibility, or security. Interface requirements define interactions among software, sensors, actuators, networks, and users. Regulatory requirements may require traceability, audit records, or validation procedures.

A useful requirement should be:

• Correct: it represents a genuine stakeholder or regulatory need.
• Unambiguous: different readers interpret it similarly.
• Complete: relevant conditions and exceptions are included.
• Consistent: it does not conflict with another requirement.
• Verifiable: inspection, analysis, demonstration, or testing can establish compliance.
• Traceable: its origin and implementation are recorded.
• Prioritised: importance and risk are known.

A requirements traceability matrix links each requirement to design elements, implementation, tests, and evidence. Traceability is especially important when a software failure could affect safety or equipment damage.

1.2 Architecture and separation of concerns

Architecture is the system’s significant structure: components, interfaces, data flows, deployment locations, and governing constraints. A small embedded monitoring system might contain sensor acquisition, signal validation, control logic, communications, data logging, and diagnostics. Separating these concerns reduces the effect of change. For example, changing a communication protocol should not require rewriting the control algorithm.

Common architectural decisions include:

• Layering: separating hardware access, services, application logic, and user interaction.
• Modularity: assigning cohesive responsibilities to components with small interfaces.
• Event-driven design: responding to interrupts, messages, or state changes.
• Client–server or service-oriented design: distributing functions across devices or services.
• Edge–cloud partitioning: executing time-critical or privacy-sensitive functions locally while using cloud resources for storage and large-scale analysis.

Architecture must reflect physical constraints. A cloud service cannot replace a local protective trip if network delay or loss could make the system unsafe. Safety-critical action should normally have a bounded, locally available path, with remote services providing supervision or optimisation.

Figure: A representative edge–cloud architecture in which local control remains available when cloud connectivity fails.

2. Estimation, planning, and risk

Estimation is a reasoned forecast, not a promise. A team should record scope, assumptions, dependencies, available people, technical uncertainty, and confidence. Decomposing work into a work breakdown structure (WBS) makes estimates more credible. Tasks should be small enough to assign, review, and test.

For a three-point estimate, the Program Evaluation and Review Technique (PERT) approximation is:

Here, O is the optimistic duration, M the most likely duration, P the pessimistic duration, and E the weighted expected duration. The estimate assumes uncertainty can reasonably be represented by these three judgements; it is not a guarantee and should not be used without examining dependencies.

If a task is estimated at 2, 5, and 14 working days respectively, E = (2 + 4×5 + 14) ÷ 6 = 36 ÷ 6 = 6 working days. The unusually large pessimistic value signals risk rather than merely increasing arithmetic.

Risk is characterised by an uncertain event, its cause, its consequence, its likelihood, and a response. A simple expected-loss model is:

where p is the probability of the event, expressed between 0 and 1, and C is its consequence in a stated unit such as monetary cost, downtime, or a defined risk score. The model assumes a meaningful consequence scale and does not capture all interactions among risks. It should support—not replace—engineering judgement.

For example, a 0.10 probability of a failure costing 20,000 currency units gives R = 0.10 × 20,000 = 2,000 currency units of expected loss. A low-probability catastrophic safety event may require mitigation even when its numerical expected loss appears modest, because safety decisions cannot be reduced to money.

Typical responses are avoid, reduce, transfer, accept, or prepare a contingency. A risk register assigns an owner, trigger, response, due date, and residual risk. It should be reviewed at milestones rather than completed once and forgotten.

3. Version control and continuous integration

Version control records the evolution of source code, documentation, configuration, tests, and sometimes hardware descriptions. A distributed system such as Git gives each contributor a local history while allowing a shared repository. A disciplined workflow commonly includes a protected main branch, short-lived feature branches, descriptive commits, pull requests, peer review, and tagged releases.

A commit should represent a coherent change. Messages such as “fix issue” are weak; “Reject sensor frames with invalid checksum” communicates intent. Branch protection should require successful automated checks before merging. Teams must also decide how to manage generated files, secrets, large binary files, dependencies, and configuration differences between development and production.

Continuous integration means that proposed changes are integrated and checked frequently. A practical pipeline may perform:

1. formatting and static analysis;
2. unit tests;
3. integration tests using simulated or real interfaces;
4. security and dependency scans;
5. build and packaging;
6. creation of test reports and traceability evidence.

CI is not synonymous with continuous deployment. Deployment to operational equipment requires additional approval, safety evaluation, rollback planning, and environment-specific validation. Automated tests are valuable but incomplete: a passing suite demonstrates only the behaviours represented by the tests.

A useful quality model includes correctness, reliability, usability, maintainability, portability, performance, and security. Metrics must be interpreted carefully. High test coverage does not prove correct requirements, and a low defect count may indicate inadequate testing or reporting rather than high quality.

4. Secure and dependable engineering practice

Security should be designed in, not added after implementation. Threat modelling asks what must be protected, who might attack it, how an attack could occur, and what controls reduce the risk. Assets may include firmware, credentials, personal data, control commands, calibration constants, and operational availability.

Core practices include least privilege, secure authentication, authorised access, input validation, safe error handling, encrypted communication where appropriate, secure update mechanisms, dependency management, logging, backup, and vulnerability response. Secrets should not be embedded in source code or committed to public repositories. A fail-safe response must be defined for communication loss, corrupted data, sensor disagreement, and resource exhaustion.

Dependability includes availability, reliability, safety, integrity, maintainability, and confidentiality. These properties can conflict. For example, extensive logging may assist diagnosis but increase storage, bandwidth, and privacy exposure. An engineering decision should document the chosen trade-off and its rationale.

5. Licensing, privacy, ethics, and governance

Software licences define permissions and obligations. Permissive licences commonly allow reuse with attribution and licence notices. Strong copyleft licences may require distribution of derivative work under specified terms. Proprietary software may impose restrictions on copying, modification, deployment, or reverse engineering. “Open source” does not mean “without conditions.” Every dependency should be inventoried, its version recorded, and its licence reviewed for the intended distribution model.

Privacy concerns arise whenever software collects information linked to identifiable people, locations, behaviour, or devices. Good practice includes purpose limitation, data minimisation, informed and meaningful consent where required, access control, retention limits, secure deletion, de-identification where appropriate, and transparent communication. De-identification is not automatically irreversible; combining datasets can sometimes re-identify individuals.

Professional ethics requires engineers to place public safety, health, and welfare above pressure to meet a deadline or commercial target. Engineers should be truthful about test results, disclose conflicts of interest, protect confidential information, respect competence boundaries, and report serious hazards through appropriate channels. Ethical responsibility remains with the engineer and organisation even when code was generated by a tool or supplied by a contractor.

Governance establishes who may decide, approve, access, change, release, and retire a system. A lightweight governance structure can include a requirements owner, technical lead, safety or security reviewer, change authority, repository administrator, and release approver. The structure should be proportionate to risk: a student data logger does not need the same controls as a grid protection relay, but neither should be unmanaged.

6. AI-assisted coding and data-driven engineering

AI coding assistants can generate boilerplate, explain unfamiliar code, propose tests, translate between languages, and identify possible defects. They can accelerate work, particularly when a human supplies precise context and evaluates the output. They can also produce insecure, inefficient, nonportable, or factually incorrect code; reproduce licence-sensitive material; expose confidential prompts; and create false confidence through plausible explanations.

A responsible workflow is:

1. define the requirement and acceptance test before requesting code;
2. avoid entering confidential designs, personal data, credentials, or export-controlled information;
3. request small, reviewable changes;
4. inspect algorithms, dependencies, error handling, and licences;
5. run static analysis, tests, security checks, and performance tests;
6. document material AI assistance where organisational policy requires it;
7. retain human accountability for the released result.

Data analytics converts collected data into descriptive, diagnostic, predictive, or prescriptive information. The analytical chain is often represented as acquire → clean → explore → model → validate → deploy → monitor. Errors in sampling, missing data, sensor calibration, label quality, or data drift can invalidate sophisticated models.

For binary classification, accuracy is:

Here, TP and TN are true positives and true negatives, while FP and FN are false positives and false negatives. The formula assumes each case has one evaluated class and that the classes and decision threshold are defined. Accuracy can be misleading with imbalanced classes; precision, recall, confusion matrices, cost-sensitive analysis, and calibration may be more informative.

Machine-learning systems should be evaluated on data not used for fitting. A training set supports learning, a validation set supports model or threshold selection, and a test set provides an approximately unbiased final estimate when kept isolated. Deployment requires monitoring for distribution shift, performance degradation, unfair outcomes, adversarial inputs, and changes in the physical process.

7. Edge, cloud, and digital twins

Edge computing places computation near sensors or actuators. It can reduce latency, bandwidth use, and dependence on connectivity, and may improve privacy by keeping raw data local. Cloud computing offers elastic storage, centralised management, large-scale analytics, and access from multiple sites. A hybrid architecture is often appropriate: deterministic control at the edge, fleet-level analysis in the cloud, and carefully controlled synchronisation between them.

The choice should consider latency, availability, energy, cost, data sovereignty, updateability, cybersecurity, and failure modes. A cloud connection is a dependency, not an assumption that can be ignored. The system should specify what happens when it is delayed, unavailable, or compromised.

A digital twin is a maintained digital representation of a physical asset or process, connected through data and models for purposes such as monitoring, diagnosis, prediction, commissioning, or maintenance. A visual model alone is not necessarily a digital twin. The representation requires defined identity, update mechanisms, relevant state variables, model assumptions, and validation against the physical system.

Digital twins have limitations. Sensors may be incomplete or biased; models may omit degradation mechanisms; synchronisation may fail; and uncertainty may be hidden by attractive dashboards. A twin should expose data quality, timestamp, model version, uncertainty, and confidence. It should not be treated as an oracle or as a substitute for physical inspection when safety decisions require direct evidence.

8. Team-based project method

A strong team begins with a project charter stating purpose, scope, stakeholders, constraints, deliverables, acceptance criteria, roles, communication practices, and definition of done. Roles should rotate where practical so that every student gains experience in requirements, implementation, testing, documentation, and review.

A useful iterative cycle is:

• establish and prioritise requirements;
• design a minimal architecture and identify hazards;
• implement a small vertical slice;
• integrate through version control and CI;
• test against acceptance criteria;
• review evidence, risks, and stakeholder feedback;
• revise the plan and release only when approval conditions are met.

The “definition of done” might require reviewed code, passing automated tests, updated documentation, no unresolved critical vulnerabilities, traceability to requirements, and a reproducible build. Project records should include decision logs, risk changes, test results, release notes, and known limitations.

Applied case: illustrative smart laboratory energy monitor

Background. An engineering department proposes a monitor that measures laboratory power use, detects abnormal demand, and displays daily summaries. The prototype includes current sensors, a microcontroller, local storage, and a cloud dashboard.

Problem. Early proposals send all measurements to the cloud and allow a cloud command to disconnect loads. The team has vague requirements, no dependency inventory, and credentials stored in the source repository.

Analysis. Loss of network connectivity could prevent local protection. Raw measurements may reveal laboratory occupancy patterns. Sensor faults could create false alarms. The team identifies safety, privacy, cybersecurity, and availability risks and ranks them by consequence and likelihood.

Approach. The revised architecture validates sensor ranges locally, logs data in a bounded buffer, and performs any protective action through a local, deterministic rule. The cloud receives minimised and aggregated data for reporting. Requirements specify sampling, alarm latency, acceptable missing-data behaviour, retention period, and recovery after restart. The team uses a private repository, protected main branch, pull requests, automated tests, dependency scanning, and a secrets manager. A traceability matrix links requirements to tests. A licence file and software bill of materials identify third-party components.

Outcome. Demonstration tests show that the monitor continues its local safety function during network loss. The dashboard reports data gaps rather than silently interpolating them. A privacy review removes unnecessary user identifiers. The team documents that the prototype is not certified for life-safety protection and requires further validation before operational deployment.

Learning points. The case illustrates that architecture, ethics, security, and project management are inseparable. The most impressive dashboard would not compensate for an unsafe control dependency, undocumented limitations, or unprotected credentials.

9. Limitations and contemporary direction

Emerging technology changes faster than institutional practice. AI models may be updated without obvious behavioural equivalence; cloud services may change pricing or interfaces; open-source dependencies may be abandoned; and digital-twin models may become stale. Engineers should design for reversibility where feasible: exportable data, replaceable interfaces, documented assumptions, tested rollback, and retirement plans.

Automation also changes professional skill requirements. Engineers need enough programming knowledge to inspect generated code, enough statistics to question model claims, enough cybersecurity knowledge to recognise attack surfaces, and enough ethical judgement to identify unacceptable risk. No tool removes the duty to understand the system being released.

Chapter Summary

Engineering software practice begins with precise, traceable requirements and an architecture that reflects physical, safety, and operational constraints. Estimation uses explicit assumptions; PERT and expected-loss calculations provide useful but limited decision support. Version control, peer review, CI, testing, and reproducible releases create engineering evidence rather than relying on informal confidence.

Security, privacy, licensing, ethics, and governance are design responsibilities. AI-assisted coding can improve productivity but requires human review, confidentiality safeguards, testing, and accountability. Analytics and machine learning depend on data quality, appropriate metrics, independent evaluation, and monitoring after deployment. Edge and cloud systems should partition functions according to latency, availability, privacy, and safety requirements. Digital twins are useful maintained representations, not automatically accurate copies of reality. A successful team project integrates these practices into a controlled, evidence-based lifecycle.

Key Terms

Requirement: A verifiable statement of a needed function, quality, or constraint.

Traceability: The ability to link a requirement to its source, design, code, test, and evidence.

Architecture: The significant structure, components, interfaces, and deployment decisions of a system.

Work breakdown structure: A decomposition of project scope into manageable tasks.

PERT: A three-point duration-estimation method using optimistic, most likely, and pessimistic estimates.

Risk register: A managed record of risks, causes, consequences, owners, responses, and status.

Version control: A system for recording and managing changes to project artefacts.

Continuous integration: Frequent integration of changes with automated build and quality checks.

Static analysis: Examination of code without executing it to identify defects or risky patterns.

Threat modelling: Structured identification of assets, threats, vulnerabilities, and mitigations.

Least privilege: Giving an actor only the access required for its authorised task.

Software licence: Legal terms governing use, modification, and distribution of software.

Privacy: Appropriate control and protection of information relating to identifiable people.

Governance: Roles, authorities, policies, approvals, and controls for responsible decisions.

Machine learning: Methods that infer patterns or predictive relationships from data.

Data drift: Change in the input or process distribution that can reduce model performance.

Edge computing: Processing performed near the data source or physical equipment.

Cloud computing: On-demand network-accessible computing and storage services.

Digital twin: A maintained digital representation connected to a physical asset or process.

Definition of done: Explicit conditions that must be satisfied before work is accepted.

Review Questions

Short Answer Questions

1. What distinguishes a functional requirement from a non-functional requirement?
2. Why should a safety-critical control function not depend exclusively on a cloud connection?
3. State two purposes of a requirements traceability matrix.
4. What is the principal purpose of continuous integration?
5. Why can classification accuracy be misleading for an imbalanced dataset?

Long Answer Questions

1. Explain how a team could progress from a stakeholder need to a tested, traceable software requirement.
2. Discuss how architecture, security, privacy, and ethics interact in an IoT engineering system.
3. Describe a responsible workflow for using an AI coding assistant in a university engineering project.
4. Compare edge and cloud computing with respect to latency, availability, privacy, cost, and maintainability.
5. Explain why a digital twin requires validation, synchronisation, and explicit model limitations.

Analytical / Application Questions

1. A task has optimistic, most likely, and pessimistic estimates of 3, 6, and 15 working days. Calculate its PERT expected duration and explain what the spread suggests about project risk.
2. A fault has probability 0.04 and consequence 50,000 currency units. Calculate its expected loss, then explain why the team might still choose mitigation rather than simple acceptance.
3. Design a high-level edge–cloud architecture for a remote motor-monitoring system. Identify one local safety function, one cloud analytics function, two security controls, and one privacy control.

Multiple Choice Questions with Answers

Question 1

Which property makes a software requirement suitable for objective assessment?

A. It is verifiable

B. It is lengthy

C. It uses technical jargon

D. It is approved verbally

Correct Answer: A. It is verifiable

Question 2

A task has optimistic duration 2 days, most likely duration 5 days, and pessimistic duration 14 days. Using PERT, what is the expected duration?

A. 5 days

B. 6 days

C. 7 days

D. 14 days

Correct Answer: B. 6 days

Question 3

What is the main purpose of a protected main branch and pull-request review?

A. To prevent all experimentation

B. To ensure changes receive controlled review before integration

C. To eliminate the need for testing

D. To make every commit larger

Correct Answer: B. To ensure changes receive controlled review before integration

Question 4

A risk has probability 0.10 and consequence 20,000 currency units. What is its simple expected loss?

A. 200 currency units

B. 1,000 currency units

C. 2,000 currency units

D. 20,000 currency units

Correct Answer: C. 2,000 currency units

Question 5

Which practice best protects credentials in a software project?

A. Embedding them in source code

B. Publishing them in documentation

C. Using a secrets-management mechanism

D. Using the same password for all systems

Correct Answer: C. Using a secrets-management mechanism

Question 6

Which statement about AI-generated code is most accurate?

A. It is correct whenever it compiles

B. It requires human review, testing, and licence consideration

C. It cannot contain security defects

D. The user has no responsibility for released code

Correct Answer: B. It requires human review, testing, and licence consideration

Question 7

For a binary classifier, which quantity represents false negatives?

A. Actual positives predicted as negative

B. Actual negatives predicted as positive

C. Actual positives predicted as positive

D. Actual negatives predicted as negative

Correct Answer: A. Actual positives predicted as negative

Question 8

Which function is generally most appropriate to keep at the edge in a safety-sensitive system?

A. Long-term fleet trend analysis

B. A locally bounded protective response

C. Organisation-wide report formatting

D. Historical data warehousing

Correct Answer: B. A locally bounded protective response

Question 9

What distinguishes a digital twin from a static visual model?

A. The twin is always perfectly accurate

B. The twin is connected to a physical asset through maintained data and models

C. The twin contains no assumptions

D. The twin eliminates the need for sensors

Correct Answer: B. The twin is connected to a physical asset through maintained data and models

Question 10

Which action is an example of data minimisation?

A. Collecting every available identifier indefinitely

B. Retaining raw data without a defined purpose

C. Collecting only data necessary for the stated engineering purpose

D. Sharing all measurements publicly

Correct Answer: C. Collecting only data necessary for the stated engineering purpose